Showing posts with label ssl. Show all posts
Showing posts with label ssl. Show all posts


TLS and SSL certificates cheat sheet

This is a summary for getting a properly-signed certificate to use with a web server. Probably the same or similar process for other servers, e.g. LDAP.

  1. Generate an RSA private key for your server.
  2. Create a Certficate Signing Request (CSR), specifying the above RSA private key as the key.
    1. Verify the CSR.
  3. Send the CSR to a Certificate Authority (CA).
  4. The CA will send back:
    1. Your signed SSL certificate, in several files in several formats. Our CA gives these four:
      1. Certificate with chain, PEM encoded - foobar_example_com.cer
      2. Certificate only, PEM encoded - foobar_example_com_cert.cer
      3. Certificate as PKCS#7, PEM encoded - foobar_example_com.crt
      4. Certificate as PKCS#7 - foobar_example_com.p7b
    2. An intermediate CA certificate file. This can be thought of as a child of the root CA certificate, which is private and protected by the CA. Our CA gives this file:
      1. Root/Intermediate(s) only, PEM encoded - foobar_example_com_interm.cer
    3. Possibly a reverse intermediate CA certificate. I am actually not certain what this is.
In the following, let’s say that the FQDN of your server is

On a Red Hat-like system, all the SSL- and TLS-related files/certificates are in the directory tree based at:


To generate the RSA private key file

# cd /etc/pki/tls/private
# openssl genpkey -algorithm RSA -out -pkeyopt rsa_keygen_bits:2048

The private key is now in:


Keep this key private, i.e. root-only access.

Next, create a CSR using that newly-created key, also specifying the FQDN to be associated with the certificate that you are requesting:

# cd /etc/pki/tls/certs

# openssl req -sha512 -new -key /etc/pki/tls/private/ -out

The CSR is the file

Verify the CSR:

# openssl req -noout -text -in

You will get output showing information in the request. Check for the “Subject” line, that it matches your geographical and company information, etc.

Send the CSR to your CA of choice. They will use that CSR to sign a certificate. The signed certificate will be sent to you, along with an intermediate CA certificate, and possibly a reverse intermediate CA certificate. 

The CA we use at my organization sends back three files:
  • foobar_example_com_cert.cer - the signed certificate
  • foobar_example_com_interm.cer - the intermediate CA certificate
  • foobar_example_com_interm_reverse.cer - the reverse intermediate CA certificate
For Red Hat-like systems, these files should be put in:
  • signed certificate - /etc/pki/tls/certs/foobar_example_com_cert.cer
  • intermediate CA certificate - /etc/pki/tls/certs/foobar_example_com_interm.cer
  • reverse intermediate CA certificate - /etc/pki/tls/certs/foobar_example_com_interm_reverse.cer
For Apache HTTPD setup, modify the file /etc/httpd/conf.d/ssl.conf

<VirtualHost _default_:443>
SSLCertificateFile /etc/pki/tls/certs/foobar_example_com_cert.cer
SSLCertificateChainFile /etc/pki/tls/certs/foobar_example_com_interm.cer

There is one more setting in that VirtualHost section, for the CA certificate bundle: the SSLCACertificateFile. This file is usually provided by a distro package. In the case of RHEL, it is provided by the ca-certificates package. The default value should be:

SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt



Logjam: another day, another https vulnerability

A vulnerability has just been discovered in https, specifically in the Diffie-Hellman key exchange. This arose from the old export restrictions set by the US, so that its law enforcement and security agencies could break encryption used by foreign entities. Ars Technica, as usual, has a good write-up.

The researchers who discovered the flaw have a dedicated website which gives pointers on what to do if you run a web server, or just a browser. They have a server scanner, or you can use the one at Qualys SSL Labs.

Ivan Ristić has some more detail on increasing the strength of DH on Apache. Unfortunately, it may not be supported by the version of Apache you happen to have running.


Another SSL vulnerability - The POODLE Attack

From the Mozilla Security Blog:
SSL version 3.0 is no longer secure. Browsers and websites need to turn off SSLv3 and use more modern security protocols as soon as possible, in order to avoid compromising users’ private information.
Under RHEL 6.5 with Apache httpd, edit /etc/httpd/conf.d/ssl.conf and make sure the protocol line disables both SSLv2 and SSLv3:
SSLProtocol all -SSLv2 -SSLv3
or you can just specify TLS only:
SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2
 Ars Technica has a good explanation.

Scott Helme has a good run down on how to fix this issue, for various servers and browsers.