Archive:Docs/Drafts/AdministrationGuide/Servers/MailServer/OpenSSL

(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:

1. There is no key in all those computers all over the world to recognize your certificate;
2. 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.For instance attached file is configured to be placed in /etc/pki/tls and work subsequent commands from that location.

1. 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. Some questions will be asked, answer by common sense, for instance call yourself MrTrustWorthyOpenSSLAuthority, etc. Place cakey.pem in /etc/pki/CA/private and cacert.pem in /etc/pki/CA/certs.
2. 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. Again, some questions will be asked. The answers you give here will be what other people will see when looking at your certificate.
3. CA signs client request, and
   • openssl ca -in req.pem -out newcert.pem -config ./openssl.cnf
4. also issues certificate revocation list
   • openssl ca -gencrl -out crl.pem -config ./openssl.cnf. Place crl.pem in /etc/pki/CA/crl//

Now

• cakey.pem will be your CA key (private part of the key). /etc/pki/CA/private is a good place to keep this. Do not publish this. You will only be using this when signing clients' certificate requests and most likely you will have to do it only once, when signing your own request.
• cacert.pem will be your CA certificate (CA identity+public part of the key). /etc/pki/CA/certs 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. You can look at this file with commandopenssl x509 -in cacert.pem -noout -text
• crl.pem will be your CA certificate revocation list. This file can be published too and some server applications are asking for it to be referenced.
• key.pem will be your client key./etc/pki/tls/private is a good place to keep this file. This is the file to be referenced in various server applications (mailserver, etc) as private key.
• newcert.pem will be your client certificate, signed by CA. /etc/pki/tls/certs is a good place to keep this. This will be referenced in various server applications as your certificate+public key.

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.