From Fedora Project Wiki

(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.)

SSL certificates are useful in many ways. For example

  • You owe domain example.com. Users are connecting to some server with some IP. Their browser window shows example.com. Can they be sure this really 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.

Many guides in FOSS community suggest generation of self-signed certificates. Here any person (with openssl implementation) can act simultaneously CA and a client. This brings two deficiencies:

  1. There is no key in the system to recognize the 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 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.

  1. Generate CA self signed certificate and key (this will ask for password)
    • openssl req -x509 -newkey rsa:1024 -keyout cakey.pem -out cacert.pem -config ./openssl.cnf
  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
  3. 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.
  4. also issues certificate revocation list
    • openssl ca -gencrl -out crl.pem -config ./openssl.cnf


Now

  • cakey.pem will be your CA key;
  • cacert.pem will be your CA certificate.
  • key.pem will be your client key..
  • 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, which flatly refuse to work with self-signed certificates. Moreover, if you publish your CA certificate cakey.pem (anywhere as a file on the web), then everyone can import it, in which case your client certificate will appear completely valid.