Regularly you set a max-age to Public-Key-Pins (HPKP) to be valid for 1 or 2 years in seconds. What about if you change before the SSL run out your SSL Certificate and Visitors still have the Public-Key-Pin of the old Certificate?
It should be done without that the Visitor has to do with the Browser.
Important distinction: Public key pinning pins the public key, not the certificate. The certificate contains the public key, but also contains a signature of the public key (and associated metadata) from a certificate authority.
How I use HPKP:
Generate 3 key pairs.
Upload one to the server, use for HTTPS.
Include the SHA256 hash of all three public keys in the HPKP header.
That gives me two backups. I keep them both on encrypted storage; one is kept on my person, the other in a safe.
Other people pin to intermediate certificates from multiple certificate authorities.
Also, a max-age of two months is adequate. Attackers also have certificate transparency (and the SSL Observatory for users with the HTTPS Everywhere extension) to contend with.
Related
I have a server and a few clients, all running on different docker containers. The users can use the client by entering localhost:3000 on their browser (where the client docker is running).
All the containers run on the same LAN. I want to use HTTPS.
Can I sign a public private key pair using my own CA, then load the CA's public key to the browser?
I want to use the normal flow for public domains, but internally with my own CA.
Or should I look for another solution?
Meta: since you've now disclosed nodejs, that makes it at least borderline for topicality.
In general, the way PKIX (as used in SSL/TLS including HTTPS) works is that the server must have a privatekey and matching certificate; this is the same whether you use a public CA or your own (as you desire). The server should also have any intermediate or 'chain' cert(s) needed to verify its cert; a public CA will always need such chain cert(s) because CABforum rules (codifying common best practice) prohibits issuing 'subscriber' (EE) certs directly from a root, while your own CA is up to you -- you can choose to use intermediate(s) or not, although as I say it is considered best practice to use them and keep the root privatekey 'offline' -- in cryptography, that means not on any system that communicates with anybody, such as in this case servers that request certificates, thus eliminating one avenue of attack -- on a specialized device that is 'airgapped' (not connected or even able to be connected to any network) and in a locked vault, possibly with 'tamper protection', a polite name for self-destruct. As a known example of the rigor needed to secure something as sensitive as the root key of an important CA, compare Stuxnet.
The client(s) does not need and should not be configured with the server cert unless you want to do pinning; it(they) do need the CA root cert. Most clients, and particularly browsers, already have many/most/all public CA root certs builtin, so using a cert from such a CA does not require any action on the client(s); OTOH using your own CA requires adding your CA cert to the client(s). Chrome on Windows uses the Microsoft-supplied (Windows) store; you can add to this explicitly (using the GUI dialog, or the certutil program or powershell), although in domain-managed environments (e.g. businesses) it is also popular to 'push' a CA cert (or certs) using GPO. Firefox uses its own truststore, which you must add to explicitly.
In nodejs you configure the privatekey, server cert, and if needed chain cert(s), as documented
PS: note you generally should, and for Chrome (and new Edge, which is actually Chromium) must, have the SubjectAlternativeName (SAN) extension in the server cert specify its domain name(s), or optionally IP address(es), NOT (or not only) the CommonName (CN) attribute as you will find in many outdated and/or incompetent instructions and tutorials on the Web. OpenSSL commandline makes it easy to do CommonName but not quite so easy to do SAN; there are many Qs on several Stacks about this. Any public CA after about 2010 does SAN automatically.
My client send me three files from Go-Daddy (86f8ac00fcd77994.crt, 86f8ac00fcd77994.pem and gd_bundle-g2-g1.crt). I need create a jks keystore from this files. Is it possible? Thanks!
PD: Sorry for my english!
Yes but you don't want to.
Java uses keystore files like JKS, and KeyStore objects in memory, to store two (or three) different kinds of information but many people imprecisely call both of them certificates and don't understand the huge and critical difference. Specifically (and changing the order from the javadoc):
a TrustedCertificate entry contains "[one] certificate ... belonging to another party. .... This type of entry can be used to authenticate other parties."
a PrivateKey entry contains a privatekey PLUS a certificate CHAIN "used by a given entity for self-authentication".
for completeness, some keystores can contain a SecretKey entry, but JKS cannot, and even with those that can this capability is rarely used.
The files you have are all certificates (one in the hex-named files, several in the bundle file), not privatekeys. You can import each of them into a TrustedCert entry, but TrustedCert entries are only used to validate the other end of a communication -- i.e. when you connect to a server, the TrustedCert entries are used to validate that server's cert, and if you accept connection from a client and request client auth (which is not the default and is rare), the TrustedCert entries are used to validate that client's cert. But since this cert was issued by GoDaddy, if it is used correctly (with its chain) by a server or client you communicate with, you don't need any TrustedCert entries because it validates against a root already in Java's default truststore.
If you wanted to use this cert to authenticate 'yourself' (that is, your system) -- for example if you wanted to run a TLS server (possibly but not necessarily an HTTPS web server) identified by this cert -- you would need a PrivateKey entry, not any TrustedCert entries, and you can't create a PrivateKey entry because you don't have the privatekey. The person who obtained this certificate from GoDaddy does have the privatekey, because the certificate request process requires it, so they could e.g. run a server, but they didn't give it to you so you can't.
Thus the answer to the question you asked -- can you put these certs in a JKS -- is yes, you can. But it's a complete waste of time, because the resulting JKS cannot be used for anything and is worthless.
I have heard that SSH does not need certificates.
But for RSA authentication of SSH , it should make sure that public key belong to the server and it can be done with certificates.
But it does not use certificates.
So how does it do?
No. It does NOT NEED them, but it CAN use them (but they are different then the certificates used in SSL! for various reasons). Certificates help only to delegate the verification to some certificate authority. To verify the public key, you just need to get the public key using "secure" channel.
So how you can verify the public key of the server you are connecting to?
There are several possibilities. The server admin will send you using different secure channel the public key of fingerprint of the public key. They can look like this:
Public key: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
You can store this one directly in your ~/.ssh/known_hosts prefixed with the server name and space.
Fingerprint SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1A bitbucket.org (RSA)
When you connect to the server for the first time, you are asked similar question:
The authenticity of host 'bitbucket.org (104.192.143.3)' can't be established.
RSA key fingerprint is SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1A.
Are you sure you want to continue connecting (yes/no)?
Then it is your responsibility to verify that the fingerprint is the same as the one you got from your admin.
If you don't do that, you are in danger that somebody redirected your connection to some malicious server and you are connecting somewhere completely else. The host keys are unique and this attacker would have different key (and therefore different fingerprint) unless he already compromised the original server (and then you are screwed already).
There is also possibility to add the host keys to the SSHFP DNS record, which will eliminate the burden above (you should have DNSSEC, otherwise the DNS records can be modified the same way as your direct connection). For this to work, you need to turn it on in your ssh_config using VerifyHostKeyDNS options.
And what about the certificates?
SSH can use certificates. This is common in company environment, where you are already given a known_hosts file configured with the certificate authority, which is used to sign all the host keys (and usually also the clients authentication keys). In that case, you don't need anything from above and connecting to local infrastructure "just works". Note, these certificates are not X509 as used in SSL/TLS PKI. For more info about these certificates, see manual page for ssh-keygen, which explains that in detail.
I am trying to set my tomcat with SSL. I have finished it. But, when I surf on my server the SSL certificate is not trusted.
I imported into my .keystore file a Certificate of one entity, but the result is the same.
This is what i want:
This is what i got
Can you help me?
If you only want a certificate that is accepted by browsers and clients "automatically", without adding an anchor to the truststore, you must get a certificate issued by one of the established Certificate Authorities that is builtin to the browser(s) and/or other client program(s) you use. (Note the CA portion of Verisign is now owned by and operates under the name of Symtanec, which also owns Thawte and Geotrust but they still operate under their prior names.)
No trusted CA will issue you a cert for the name "localhost", only for a publicly resolvable and reachable domain name that you own, so if you don't have a domain name you'll have to get that first. Some suppliers, like GoDaddy, do both DNS and certificates (and other things like hosting); you may or may not prefer a single supplier. (Or you may be able get a cert for a static public address, but that's harder to get and harder for people to use.)
If you want the green bar in browsers, that requires Extended Validation which costs more, typically USD 300 and up, and you must prove your legal identity and status by government records. To do this in practice you must be a business, registered and licensed as appropriate for your location.
I've created a subdomain for my parse app and I need to protect the connection while logging and during my session.
Assume that I don't have any public domain name and I will still use just the url of (mysubdomain.parseapp.com) then is all I need to get buy a certificate and get the two files for:
SSL Public Certificate
SSL Private Key
and just upload it to parse through the settings page ? or will I need to do something else ?
Just need a confirmation that my understanding is correct.
Kind Regards,
Robear
The private key would come from the server. A Certificate Authority is only going to give you a domain cert. For example "mysubdomain_parseapp.com_crt" and yes you'll need to upload the domain cert, private key (which is generated during the CSR request), plus the CA's intermediate cert (the CA should advise which one and where to download it).
In order for a CA to issue out a cert. You need to own the root domain or have permission by the owner. In your case you would need to prove that your the owner or have permision to purchase an SSL cert with "parseapp.com"