(I have not contributed for a while and after typing this up, I realized I do not remember styles and tags. I will come back to this in couple of days with proper style.)
OpenSSl
SSL certificates are useful in many ways. For example
- You own domain example.com. Users are connecting to some server with some IP. Their browser window shows example.com. Can they be sure this really is example.com? May be someone has messed up with DNS and the name example.com is pointing to the IP of some Mr. Crook?
- You run a mail server and need SSL certificate to establish secured connection between mailserver and a client
Commercial SSL is typically hierarchical. Normally there is certificate authority (CA) and a client. Public key of major CA's are included in OS (check out /etc/pki/tls/cert.pem), so client certificates signed by them are recognized out of box.CA will put a client through some verification before signing his certificate, so that Mr. Crook can not obtain a signed certificate example.com from any reputable CA.
Present guide is for those who for one reason or another do not want to get SSL certificate from one of those accepted vendors and instead are looking for some free alternatives.
Many guides in FOSS community suggest generation of self-signed single certificate. Here any person (with openssl implementation) can act simultaneously as CA and a client. This brings two deficiencies:
- There is no key in all those computers all over the world to recognize your certificate;
- The certificate is self-signed, someone is certifying self. May be Mr. Crook is certifying himself as example.com?
We recommend eliminating at least Nr. 2 problem by switching to two tier hierarchy. You will generate two certificates: one for CA and the other for client. You will be using client certificate, which no more will be self-signed. You will have to: Warning: Directory for SSL is /etc/pki. First explore this folder. Also take a look at file openssl.cnf. Make sure that relative path for various activities to follow is valid. You can modify this file and use a custom copy in your commands.
- Generate CA self signed certificate and a key (this will ask for password)
openssl req -x509 -newkey rsa:1024 -keyout cakey.pem -out cacert.pem -config ./openssl.cnf
- Generate clients key and a request to CA to sign the certificate (-nodes is for no password)
openssl req -nodes -newkey rsa:1024 -keyout key.pem -out req.pem -config ./openssl.cnf
- CA signs client request, and
openssl ca -in req.pem -out newcert.pem -config ./openssl.cnf- Warning: Be careful to correctly follow path in the openssl.cnf file and move cakey.pem key as needed by config.
- also issues certificate revocation list
openssl ca -gencrl -out crl.pem -config ./openssl.cnf
Now
- cakey.pem will be your CA key (private part). '/etc/pki/CA/private' is a good place to keep this. Do not publish this.
- cacert.pem will be your CA certificate (public part). /etc/pki/CA' is a good place to keep this. You might want to pass this one around. Folks having this file imported in their system can recognize certificates signed by cakey.pem.
- key.pem will be your client key.'/etc/pki
- newcert.pem will be your client certificate, signed by CA
Your client certificate newcert.pem will still have the problem of having to verifiable root (Your cakey.pem is not included in everyones' system) but will no more be self-signed. This will help with some software (for instance kmail has been reported), which flatly refuse to work with self-signed certificates. Moreover, if you publish your CA certificate cakey.pem (as a file, say hook it on the web or email people), then everyone can import it, in which case your client certificate will appear completely valid.