1 OpenSSL Command Line

Before you do any work, you should know which OpenSSL version you’ll be using. TLS and PKI continue to develop at a fairly rapid pace, and you may find that what you can do is limited if your version of OpenSSL doesn’t support them. Here’s what I get for version information with openssl version on Ubuntu 20.04 LTS, which is the system that I’ll be using for the examples in this chapter:

$ openssl version
OpenSSL 1.1.1f  31 Mar 2020

At the time of this writing, OpenSSL 1.1.1 is the main release branch and has all the nice features. On older systems, you may find a release from the 1.1.0 branch, which is fine because it can be used securely with TLS 1.2, but it won’t support modern features, such as TLS 1.3. The next branch will be OpenSSL 3.0. This branch is a major update of the libraries, with substantial architectural changes and a switch to the Apache License 2.0 for better interoperability with other programs and libraries. That said, the command-line tooling, which is what I am covering here, is not expected to change much.

To get complete version information, use the -a switch:

$ openssl version -a
OpenSSL 1.1.1f  31 Mar 2020
built on: Mon Apr 20 11:53:50 2020 UTC
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(int) blowfish(ptr) 
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 ↩
-fdebug-prefix-map=/build/openssl-P_ODHM/openssl-1.1.1f=. -fstack-protector-strong ↩
-Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE ↩
-DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT ↩
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM ↩
-DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256↩
_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
Seeding source: os-specific

I don’t suppose that you would find this output very interesting initially, but it’s useful to know where you can find out how your OpenSSL was compiled. Of special interest is the OPENSSLDIR setting, which in my example points to /usr/lib/ssl; it will tell you where OpenSSL looks for its default configuration and root certificates. On my system, that location is essentially an alias for /etc/ssl, Ubuntu’s main location for PKI-related files:

lrwxrwxrwx  1 root root   14 Apr 20 11:53 certs -> /etc/ssl/certs
drwxr-xr-x  2 root root 4096 May 14 21:38 misc
lrwxrwxrwx  1 root root   20 Apr 20 11:53 openssl.cnf -> /etc/ssl/openssl.cnf
lrwxrwxrwx  1 root root   16 Apr 20 11:53 private -> /etc/ssl/private

The misc/ folder contains a few supplementary scripts, the most interesting of which are the scripts that allow you to implement a private certification authority (CA). You may or may not end up using it, but later in this chapter I will show you how to do the equivalent work from scratch.

In most cases, you will be using the system-supplied version of OpenSSL, but sometimes there are good reasons to use a newer or indeed an older version. For example, if you have an older system, it may be stuck with a version of OpenSSL that does not support TLS 1.3. On the other side, newer OpenSSL versions might not support SSL 2 or SSL 3. Although this is the right thing to do in a general case, you’ll need support for these older features if your job is to test systems for security.

You can start by downloading the most recent version of OpenSSL (in my case, 1.1.1g):

$ wget https://www.openssl.org/source/openssl-1.1.1g.tar.gz

The next step is to configure OpenSSL before compilation. For this, you will usually use the config script, which first attempts to guess your architecture and then runs through the configuration process:

$ ./config \
--prefix=/opt/openssl \
--openssldir=/opt/openssl \
no-shared \
-DOPENSSL_TLS_SECURITY_LEVEL=2 \
enable-ec_nistp_64_gcc_128

The automated architecture detection can sometimes fail (e.g., with older versions of OpenSSL on OS X), in which case you should instead invoke the Configure script with the explicit architecture string. The configuration syntax is otherwise the same.

Unless you’re sure you want to do otherwise, it is essential to use the --prefix option to install OpenSSL to a private location that doesn’t clash with the system-provided version. Getting this wrong may break your server. The other important option is no-shared, which forces static linking and makes self-contained command-line tools. If you don’t use this option, you’ll need to play with your LD_LIBRARY_PATH configuration to get your tools to work.

When compiling OpenSSL 1.1.0 or later, the OPENSSL_TLS_SECURITY_LEVEL option configures the default security level, which establishes default minimum security requirements for all library users. It’s very useful to set this value at compile time as it can be used to prevent configuration mistakes. I discuss security levels in more detail later in this chapter.

The enable-ec_nistp_64_gcc_128 parameter activates optimized versions of certain frequently used elliptic curves. This optimization depends on a compiler feature that can’t be automatically detected, which is why it’s disabled by default. The complete set of configuration options is available on the OpenSSL wiki.7

If you’re compiling a version before 1.1.0, you’ll need to build the dependencies first:

$ make depend

OpenSSL 1.1.0 and above will do this automatically, so you can proceed to build the main package with the following:

$ make
$ make test
$ sudo make install

You’ll get the following in /opt/openssl:

drwxr-xr-x 2 root root  4096 Jun  3 08:49 bin
drwxr-xr-x 2 root root  4096 Jun  3 08:49 certs
drwxr-xr-x 3 root root  4096 Jun  3 08:49 include
drwxr-xr-x 4 root root  4096 Jun  3 08:49 lib
drwxr-xr-x 6 root root  4096 Jun  3 08:48 man
drwxr-xr-x 2 root root  4096 Jun  3 08:49 misc
-rw-r--r-- 1 root root 10835 Jun  3 08:49 openssl.cnf
drwxr-xr-x 2 root root  4096 Jun  3 08:49 private

The private/ folder is empty, but that’s normal; you do not yet have any private keys. On the other hand, you’ll probably be surprised to learn that the certs/ folder is empty too. OpenSSL does not include any root certificates; maintaining a trust store is considered outside the scope of the project. Luckily, your operating system probably already comes with a trust store that you can use immediately. The following worked on my server:

$ cd /opt/openssl
$ sudo rmdir certs
$ sudo ln -s /etc/ssl/certs

OpenSSL is a cryptographic toolkit that consists of many different utilities. I counted 48 in my version. If there was ever an appropriate time to use the phrase Swiss Army knife of cryptography, this is it. Even though you’ll use only a handful of the utilities, you should familiarize yourself with everything that’s available because you never know what you might need in the future.

To get an idea of what is on offer, simply request help:

$ openssl help

The first part of the help output lists all available utilities. To get more information about a particular utility, use the man command followed by the name of the utility. For example, man ciphers will give you detailed information on how cipher suites are configured. However, man openssl-ciphers should also work:

Standard commands
asn1parse         ca                ciphers           cms               
crl               crl2pkcs7         dgst              dhparam           
dsa               dsaparam          ec                ecparam           
enc               engine            errstr            gendsa            
genpkey           genrsa            help              list              
nseq              ocsp              passwd            pkcs12            
pkcs7             pkcs8             pkey              pkeyparam         
pkeyutl           prime             rand              rehash            
req               rsa               rsautl            s_client          
s_server          s_time            sess_id           smime             
speed             spkac             srp               storeutl          
ts                verify            version           x509 

The help output doesn’t actually end there, but the rest is somewhat less interesting. In the second part, you get the list of message digest commands:

Message Digest commands (see the `dgst' command for more details)
blake2b512        blake2s256        gost              md4               
md5               rmd160            sha1              sha224            
sha256            sha3-224          sha3-256          sha3-384          
sha3-512          sha384            sha512            sha512-224        
sha512-256        shake128          shake256          sm3

And then in the third part, you’ll see the list of all cipher commands:

Cipher commands (see the `enc' command for more details)
aes-128-cbc       aes-128-ecb       aes-192-cbc       aes-192-ecb       
aes-256-cbc       aes-256-ecb       aria-128-cbc      aria-128-cfb      
aria-128-cfb1     aria-128-cfb8     aria-128-ctr      aria-128-ecb      
aria-128-ofb      aria-192-cbc      aria-192-cfb      aria-192-cfb1     
aria-192-cfb8     aria-192-ctr      aria-192-ecb      aria-192-ofb      
aria-256-cbc      aria-256-cfb      aria-256-cfb1     aria-256-cfb8     
aria-256-ctr      aria-256-ecb      aria-256-ofb      base64            
bf                bf-cbc            bf-cfb            bf-ecb            
bf-ofb            camellia-128-cbc  camellia-128-ecb  camellia-192-cbc  
camellia-192-ecb  camellia-256-cbc  camellia-256-ecb  cast              
cast-cbc          cast5-cbc         cast5-cfb         cast5-ecb         
cast5-ofb         des               des-cbc           des-cfb           
des-ecb           des-ede           des-ede-cbc       des-ede-cfb       
des-ede-ofb       des-ede3          des-ede3-cbc      des-ede3-cfb      
des-ede3-ofb      des-ofb           des3              desx              
rc2               rc2-40-cbc        rc2-64-cbc        rc2-cbc           
rc2-cfb           rc2-ecb           rc2-ofb           rc4               
rc4-40            seed              seed-cbc          seed-cfb          
seed-ecb          seed-ofb          sm4-cbc           sm4-cfb           
sm4-ctr           sm4-ecb           sm4-ofb  

OpenSSL does not come with a collection of trusted root certificates (also known as a root store or a trust store), so if you’re installing from scratch you’ll have to find them somewhere else. One possibility is to use the trust store built into your operating system, as I’ve shown earlier. This choice is usually fine, but the built-in trust stores may not always be up to date. Also, in a mixed environment there could be meaningful differences between the default stores in a variety of systems. A consistent and possibly better choice—but one that involves more work—is to reuse Mozilla’s work. Mozilla put a lot of effort into maintaining a transparent and up-to-date root store for use in Firefox.9

Because it’s open source, Mozilla keeps the trust store in the source code repository:

https://hg.mozilla.org/releases/mozilla-beta/file/tip/security/nss/lib/ckfw/builtins↩
/certdata.txt

Unfortunately, its certificate collection is in a proprietary format, which is not of much use to others as is. If you don’t mind getting the collection via a third party, the Curl project provides a regularly updated conversion in Privacy-Enhanced Mail (PEM) format, which you can use directly:

http://curl.haxx.se/docs/caextract.html

If you’d rather work directly with Mozilla, you can convert its data using the same tool that the Curl project is using. You’ll find more information about it in the following section.

At this point, what you have is a root store with all trusted certificates in the same file. This will work fine if you’re only going to be using it with, say, the s_client tool. In that case, all you need to do is point the -CAfile switch to your root store. Replacing the root store on a server will require more work, depending on what operating system is used.

On Ubuntu, for example, you’ll need to replace the contents of the /etc/ssl/certs folder. Ubuntu ships with a tool called update-ca-certificates that might work. Alternatively, you could make the changes manually by replicating the structure of the existing data. From the looks of it, that folder contains the trusted certificates as individual files, as well as all of them in a single file called ca-certificates.crt. You will also observe some symbolic links; they are created by the OpenSSL’s rehash or c_rehash tools. The drawback of any manual changes is that they may be overwritten when the system is updated.

https://raw.githubusercontent.com/curl/curl/master/lib/mk-ca-bundle.pl

$ ./mk-ca-bundle.pl 
SHA256 of old file: 0
Downloading certdata.txt ...
Get certdata with curl!
[...]
Downloaded certdata.txt
SHA256 of new file: cc6408bd4be7fbfb8699bdb40ccb7f6de5780d681d87785ea362646e4dad5e8e
Processing  'certdata.txt' ...
Done (138 CA certs processed, 30 skipped).

The first step in preparing to run a TLS server is to generate a private key. Before you begin, you must make several decisions:

To generate an RSA key, use the following genpkey command:

$ openssl genpkey -out fd.key \
-algorithm RSA \
-pkeyopt rsa_keygen_bits:2048 \
-aes-128-cbc
..........................................+++++
...................................................................+++++
Enter PEM pass phrase: ************
Verifying - Enter PEM pass phrase: ************

Here, I specified that the key be protected with AES-128. You can also use AES-256 (with the -aes-256-cbc switch), but it’s best to stay away from the other algorithms (e.g., DES, 3DES, and SEED).

When you use the genpkey command, the generated private keys are stored in PKCS#8 format,11 which is just text and doesn’t look like much:

$ cat fd.key
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFLTBXBgkqhkiG9w0BBQ0wSjApBgkqhkiG9w0BBQwwHAQInW7GrFjUhUcCAggA
MAwGCCqGSIb3DQIJBQAwHQYJYIZIAWUDBAEqBBBn8AErtRKB9p7ii1+g2OhWBIIE
0MnC2dwGznZqpTMX0MYekzyxe4dKlJiIsVr1hgwmjFifzEBs/KvHBV3eIe9wDAzq
[21 lines removed...]
IfveVZzM6PLbDaysxX6jEgi4xVbqWugd9h3eAPeBv9Z5iZ/bZq5hMbt37ElA2Rnh
RfmWSzlASjQi4XAHVLCs6XmULCda6QGvyB7WXxuzbhOv3C6BPXR49z6S1MFvOyDA
2oaXkfS+Ip3x2svgFJj/VpYZHUHwRCzXcDl/CdVg9fxwxcYHuJDH16Qfue/LRtiJ
hqr4fHrnbbk+MZpDaU+h4shLRBg2dONdUEzhPkpdOOkF
-----END ENCRYPTED PRIVATE KEY-----

However, a private key isn’t just a blob of random data, even though that’s what it looks like at a glance. You can see a key’s structure using the following rsa command:

$ openssl pkey -in fd.key -text -noout
Enter pass phrase for fd.key: ****************
RSA Private-Key: (2048 bit, 2 primes)
modulus:
    00:be:79:08:22:1a:bc:78:3c:17:34:4a:d3:5f:2b:
    [...]
publicExponent: 65537 (0x10001)
privateExponent:
    10:20:95:54:b5:e8:d1:51:5d:31:9b:48:4c:5d:90:
    [...]
prime1:
    00:f5:3f:74:cf:ef:8f:93:e9:54:b3:79:a1:f2:91:
    5a:7e:15:13:26:f7:f9:d7:a8:f3:f9:6b:2b:90:93:
    57:54:cc:84:c9:ea:6f:9f:39:ad:ad:60:4c:f0:68:
    16:db:1a:49:51:56:87:f1:70:ae:c9:42:89:2a:38:
    55:3e:17:a0:78:a7:52:49:10:79:cf:99:ae:53:c8:
    e0:60:5d:7e:91:26:86:3b:79:d2:70:c0:39:38:dd:
    ed:ee:75:c0:15:c6:30:51:00:a8:93:f3:8b:25:01:
    04:25:72:fc:9c:e9:73:d0:93:11:2d:82:e2:e3:d0:
    66:c0:36:2f:b6:de:de:0d:47
prime2:
    00:c6:d2:ce:66:b5:35:6b:35:d7:bb:b0:e3:f4:2d:
    [...]
exponent1:
    00:e9:2e:e9:b9:5f:f5:2b:54:fa:c5:1f:4c:7d:5f:
    [...]
exponent2:
    00:83:ea:bc:ad:a2:cf:a5:a9:9c:d0:d8:85:f6:ae:
    [...]
coefficient:
    68:18:a7:4f:aa:86:a7:e0:92:49:76:8d:24:65:fa:
    [...]

If you need to have just the public part of a key separately, you can do that with the following rsa command:

$ openssl pkey -in fd.key -pubout -out fd-public.key
Enter pass phrase for fd.key: ****************

If you look into the newly generated file, you’ll see that the markers clearly indicate that the contained information is indeed public:

$ cat fd-public.key
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvnkIIhq8eDwXNErTXytD
U1JGrYUgFsN8IgFVMJmAuY15dBvSCO+6y9FA0H08utJVtHScyWeOlo1uo0TQ3RWr
Pe7W3O2SaW2gIby2cwzGf/FBExZ+BCNXkN5z8Kd38PXDLt8ar+7MJ3vrb/sW7zs2
v+rtfRar2RmhDPpVvI6sugCeHrvYDGdA/gIZAMMg3pVFivPpHnTH4AR7rTzWCWlb
nCB3z2FVYpvumrY8TvIo5OioD2I+TQyvlxDRo14QWxIdZxvPcCUxXMN9MC8fBtLu
IlllDmah8JzF2CF5IxVgVhi7hyTtSQfKsK91tAvN30F9qkZNEpjNX37M5duHUVPb
tQIDAQAB
-----END PUBLIC KEY-----

It’s good practice to verify that the output contains what you’re expecting. For example, if you forget to include the -pubout switch on the command line, the output will contain your private key instead of the public key.

The process is similar for ECDSA keys, except that it isn’t possible to create keys of arbitrary sizes. Instead, for each key you select a named curve, which controls key size, but it controls other EC parameters as well. The following example creates a 256-bit ECDSA key using the P-256 (or secp256r1) named curve:

$ openssl genpkey -out fd.key \
-algorithm EC  \
-pkeyopt ec_paramgen_curve:P-256 \
-aes-128-cbc
Enter PEM pass phrase: ****************
Verifying - Enter PEM pass phrase: ****************

OpenSSL supports many named curves, but for web server keys, you’re generally (still) limited to only two curves that are widely supported: P-256 (also known as secp256r1 or prime256v1) and P-384 (secp384r1). Of these two, P-256 is sufficiently secure and provides better performance. If you’re curious to see a list of all named curves supported by OpenSSL, you can get it using the ecparam command and the -list_curves switch.

The recent additions x25519, x448, ed25519, and ed448 are also supported, but they are different types of curves and have to be specified using the -algorithm switch—for example:

$ openssl genpkey -algorithm ed25519
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEIF6K3m4WM7/yMA9COn6HYyx7PjJCIzY7bnBoKupYgdTL
-----END PRIVATE KEY-----

Once you have a private key, you can proceed to create a Certificate Signing Request (CSR). This is a formal request asking a CA to sign a certificate, and it contains the public key of the entity requesting the certificate and some information about the entity. This data will all be part of the certificate. A CSR is always signed with the private key corresponding to the public key it carries.

CSR creation is usually an interactive process during which you’ll be providing the elements of the certificate distinguished name. Read the instructions given by the openssl tool carefully; if you want a field to be empty, you must enter a single dot (.) on the line, rather than just hit Return. If you do the latter, OpenSSL will populate the corresponding CSR field with the default value. (This behavior doesn’t make any sense when used with the default OpenSSL configuration, which is what virtually everyone does. It does make sense once you realize you can actually change the defaults, either by modifying the OpenSSL configuration or by providing your own configuration files.)

$ openssl req -new -key fd.key -out fd.csr
Enter pass phrase for fd.key: ****************
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:GB
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:London
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Feisty Duck Ltd
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:www.feistyduck.com
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

After a CSR is generated, use it to sign your own certificate and/or send it to a public CA and ask it to sign the certificate. Both approaches are described in the following sections. But before you do that, it’s a good idea to double-check that the CSR is correct. Here’s how:

$ openssl req -text -in fd.csr -noout
Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: C = GB, L = London, O = Feisty Duck Ltd, CN = www.feistyduck.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:8a:d5:de:69:30:c7:77:b0:a0:54:f7:b3:34:9a:
                    96:1c:23:81:e3:9c:0c:81:a6:8a:a5:14:76:f4:4c:
                    b3:10:cb:ee:50:d1:ea:70:e9:7f:8f:75:67:f9:12:
                    83:b0:11:e7:6c:64:de:bc:af:bd:3f:43:da:b8:41:
                    96:75:34:63:85
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        Attributes:
            a0:00
    Signature Algorithm: ecdsa-with-SHA256
         30:44:02:20:52:b9:cf:ca:d1:25:1c:b7:57:65:fb:24:5d:95:
         15:f0:39:79:36:6c:d6:0a:42:6e:26:7c:54:e8:71:17:a5:99:
         02:20:5a:e0:cd:b3:60:ec:2c:fc:29:8c:f9:21:01:08:9a:a3:
         0d:fc:9a:d3:4f:24:fb:23:4f:c6:d7:a2:14:d1:54:f9

You can save yourself some typing if you’re renewing a certificate and don’t want to make any changes to the information presented in it. With the following command, you can create a brand-new CSR from an existing certificate:

$ openssl x509 -x509toreq -in fd.crt -out fd.csr -signkey fd.key

CSR generation doesn’t have to be interactive. Using a custom OpenSSL configuration file, you can both automate the process (as explained in this section) and do certain things that are not possible interactively (e.g., how to have multiple domain names in the same certificate, as discussed in subsequent sections).

For example, let’s say that we want to automate the generation of a CSR for www.feistyduck.com. We would start by creating a file fd.cnf with the following contents:

[req]
prompt = no
distinguished_name = dn
req_extensions = ext
input_password = PASSPHRASE

[dn]
CN = www.feistyduck.com
emailAddress = webmaster@feistyduck.com
O = Feisty Duck Ltd
L = London
C = GB

[ext]
subjectAltName = DNS:www.feistyduck.com,DNS:feistyduck.com

Now you can create the CSR directly from the command line:

$ openssl req -new -config fd.cnf -key fd.key -out fd.csr

If you’re configuring a TLS server for your own use or for a quick test, sometimes you don’t want to go to a CA for a publicly trusted certificate. It’s much easier just to use a self-signed certificate.13

If you already have a CSR, create a certificate using the following command:

$ openssl x509 -req -days 365 -in fd.csr -signkey fd.key -out fd.crt
Signature ok
subject=C = GB, L = London, O = Feisty Duck Ltd, CN = www.feistyduck.com
Getting Private key
Enter pass phrase for fd.key: ****************

You don’t actually have to create a CSR in a separate step. The following command creates a self-signed certificate starting with a key alone:

$ openssl req -new -x509 -days 365 -key fd.key -out fd.crt

If you don’t wish to be asked any questions, use the -subj switch to provide the certificate subject information on the command line:

$ openssl req -new -x509 -days 365 -key fd.key -out fd.crt \
 -subj "/C=GB/L=London/O=Feisty Duck Ltd/CN=www.feistyduck.com"

By default, certificates produced by OpenSSL have only one common name and are valid for only one hostname. Because of this, even if you have related web sites, you are forced to use a separate certificate for each site. In this situation, using a single multidomain certificate makes much more sense. Further, even when you’re running a single web site, you need to ensure that the certificate is valid for all possible paths that end users can take to reach it. In practice, this means using at least two names, one with the www prefix and one without (e.g., www.feistyduck.com and feistyduck.com).

There are two mechanisms for supporting multiple hostnames in a certificate. The first is to list all desired hostnames using an X.509 extension called Subject Alternative Name (SAN). The second is to use wildcards. You can also use a combination of the two approaches when it’s more convenient. In practice, for most sites, you can specify a bare domain name and a wildcard to cover all the subdomains (e.g., feistyduck.com and *.feistyduck.com).

First, place the extension information in a separate text file. I’m going to call it fd.ext. In the file, specify the name of the extension (subjectAltName) and list the desired hostnames, as in the following example:

subjectAltName = DNS:*.feistyduck.com, DNS:feistyduck.com

Then, when using the x509 command to issue a certificate, refer to the file using the -extfile switch:

$ openssl x509 -req -days 365 \
-in fd.csr -signkey fd.key -out fd.crt \
-extfile fd.ext

The rest of the process is no different from before. But when you examine the generated certificate afterward (see the next section), you’ll find that it contains the SAN extension:

X509v3 extensions:
    X509v3 Subject Alternative Name: 
        DNS:*.feistyduck.com, DNS:feistyduck.com

Certificates don’t look like much in a text editor, but they contain a great deal of information; you just need to know how to unpack it. The x509 command does just that, so let’s use it to look at the self-signed certificates you generated.

In the following example, I use the -text switch to print certificate contents and -noout to reduce clutter by not printing the encoded certificate itself (which is the default behavior):

$ openssl x509 -text -in fd.crt -noout
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            76:bc:fb:f6:06:0e:61:eb:99:5e:83:ea:ef:92:0b:32:4f:fd:3b:51
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C = GB, L = London, O = Feisty Duck Ltd, CN = www.feistyduck.com
        Validity
            Not Before: Aug 15 09:31:54 2020 GMT
            Not After : Aug 15 09:31:54 2021 GMT
        Subject: C = GB, L = London, O = Feisty Duck Ltd, CN = www.feistyduck.com
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:8a:d5:de:69:30:c7:77:b0:a0:54:f7:b3:34:9a:
                    96:1c:23:81:e3:9c:0c:81:a6:8a:a5:14:76:f4:4c:
                    b3:10:cb:ee:50:d1:ea:70:e9:7f:8f:75:67:f9:12:
                    83:b0:11:e7:6c:64:de:bc:af:bd:3f:43:da:b8:41:
                    96:75:34:63:85
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Subject Alternative Name: 
                DNS:*.feistyduck.com, DNS:feistyduck.com
    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:20:4d:36:34:cd:e9:3e:df:18:52:e7:74:c4:a1:97:
         91:6a:e7:c1:6d:12:01:63:d1:fd:90:28:32:70:24:5c:be:35:
         02:21:00:bd:02:64:c9:8b:27:8f:79:c7:a4:41:7c:31:2f:98:
         29:3e:db:8c:f3:f1:d7:bb:fa:fe:95:48:be:16:e1:ab:1b

Self-signed certificates usually contain only the most basic certificate data, and most of it is self-explanatory. In essence, there’s the main body of the certificate, to which a signature is added. By comparison, certificates issued by public CAs are much more interesting, as they contain a number of additional fields (via the X.509 extension mechanism).

When you look at a public certificate, in the first part of the output you will find information that is similar to that in self-signed certificates. In fact, the only difference will be that this certificate has a different parent, as indicated by the issuer information.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:5e:50:53:75:08:1a:f2:7d:27:64:4f:d5:6f:1a:02:07:89
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
        Validity
            Not Before: Aug  2 23:10:45 2020 GMT
            Not After : Oct 31 23:10:45 2020 GMT
        Subject: CN = www.feistyduck.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:c8:14:4f:33:9a:db:bb:e7:e3:78:93:46:5d:56:
                    a7:bc:58:86:43:dc:ea:c1:01:52:4b:0f:20:b7:38:
                    [...]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            [...]

The main differences are going to be in the X.509 extensions, which contain a great deal of very interesting information. Let’s examine what’s in the extensions and why it’s there, in no particular order.

The Basic Constraints extension is used to mark certificates as belonging to a CA, giving them the ability to sign other certificates. Non-CA certificates will either have this extension omitted or will have the value of CA set to FALSE. This extension is critical, which means that all software-consuming certificates must understand its meaning.

X509v3 Basic Constraints: critical
    CA:FALSE

The Key Usage (KU) and Extended Key Usage (EKU) extensions restrict what a certificate can be used for. If these extensions are present, then only the listed uses are allowed. If the extensions are not present, there are no use restrictions. What you see in this example is typical for a web server certificate, which, for example, does not allow for code signing:

X509v3 Key Usage: critical
    Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
    TLS Web Server Authentication, TLS Web Client Authentication

The CRL Distribution Points extension lists the addresses where the CA’s Certificate Revocation List (CRL) information can be found. This information is important in cases in which certificates need to be revoked. CRLs are CA-signed lists of revoked certificates, published at regular time intervals (e.g., seven days). Let’s Encrypt doesn’t provide CRLs, so I took the following snippet from another certificate:

X509v3 CRL Distribution Points:
    Full Name:
      URI:http://crl.starfieldtech.com/sfs3-20.crl

The Certificate Policies extension is used to indicate the policy under which the certificate was issued. For example, this is where you can expect to find an indication of the type of validation used to ascertain the identity of the owner. Extended validation (EV) indicators can be found (as in the example that follows). These indicators are in the form of unique object identifiers (OIDs), some of which are generic and some specific to the issuing CA. In the following example, the OID 2.23.140.1.2.1 indicates a domain-validated certificate. In addition, this extension often contains one or more Certificate Policy Statement (CPS) points, which are usually web pages or PDF documents.

X509v3 Certificate Policies: 
    Policy: 2.23.140.1.2.1
    Policy: 1.3.6.1.4.1.44947.1.1.1
      CPS: http://cps.letsencrypt.org

The Authority Information Access (AIA) extension usually contains two important pieces of information. First, it lists the address of the CA’s Online Certificate Status Protocol (OCSP) responder, which can be used to check for certificate revocation in real time. The extension may also contain a link to where the issuer’s certificate (the next certificate in the chain) can be found. These days, server certificates are rarely signed directly by trusted root certificates, which means that users must include one or more intermediate certificates in their configuration. Mistakes are easy to make and will invalidate the certificates. Some clients will use the information provided in this extension to fix an incomplete certificate chain, but many clients won’t.

Authority Information Access: 
    OCSP - URI:http://ocsp.int-x3.letsencrypt.org
    CA Issuers - URI:http://cert.int-x3.letsencrypt.org/

The Subject Key Identifier and Authority Key Identifier extensions establish unique subject and authority key identifiers, respectively. The value specified in the Authority Key Identifier extension of a certificate must match the value specified in the Subject Key Identifier extension in the issuing certificate. This information is very useful during the certification path-building process, in which a client is trying to find all possible paths from a leaf (server) certificate to a trusted root. Certification authorities will often use one private key with more than one certificate, and this field allows software to reliably identify which certificate can be matched to which key. In the real world, many certificate chains supplied by servers are invalid, but that fact often goes unnoticed because browsers are able to find alternative trust paths.

X509v3 Subject Key Identifier: 
    A1:EC:11:C6:E1:E8:F7:E6:98:85:FA:9A:53:F8:B8:F1:D6:88:F9:A3
X509v3 Authority Key Identifier: 
    keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1

The Subject Alternative Name extension is used to list all the hostnames for which the certificate is valid. This extension used to be optional; if it isn’t present, clients fall back to using the information provided in the Common Name (CN), which is part of the Subject field. If the extension is present, then the content of the CN field is ignored during validation.

X509v3 Subject Alternative Name:
    DNS:www.feistyduck.com, DNS:feistyduck.com

Finally, the most recent addition is the Certificate Transparency (CT) extension, which is used to carry proof of logging to various public CT logs. Depending on the certificate lifetime, you can expect to see anywhere from two to five Signed Certificate Timestamps (SCTs). There isn’t a single set of unified requirements for the numbers and types of SCTs that are necessary to recognize a certificate as valid. Technically, it’s up to every client to specify what they expect. In practice, Chrome was the first browser to require CT and other clients are likely to follow its lead.14

CT Precertificate SCTs: 
    Signed Certificate Timestamp:
        Version   : v1 (0x0)
        Log ID    : 5E:A7:73:F9:DF:56:C0:E7:B5:36:48:7D:D0:49:E0:32:
                    7A:91:9A:0C:84:A1:12:12:84:18:75:96:81:71:45:58
        Timestamp : Aug  3 00:10:45.300 2020 GMT
        Extensions: none
        Signature : ecdsa-with-SHA256
                    30:45:02:21:00:BB:7F:D0:E1:E6:CD:4B:E7:79:30:AE:
                    BE:F6:50:4F:36:A4:F6:1D:65:21:1A:05:A9:B3:F0:53:
                    BA:FA:AC:6D:FB:02:20:52:23:B9:F9:B6:73:34:7F:3D:
                    7F:42:5C:E3:9D:3D:DA:D8:7F:B3:7E:21:0C:27:54:9B:
                    DA:E1:3F:0F:8E:09:60
    [...]

Private keys and certificates can be stored in a variety of formats, which means that you’ll often need to convert them from one format to another. The most common formats are:

$ openssl x509 -inform PEM -in fd.pem -outform DER -out fd.der

$ openssl x509 -inform DER -in fd.der -outform PEM -out fd.pem

$ openssl pkcs12 -export \
    -name "My Certificate" \
    -out fd.p12 \
    -inkey fd.key \
    -in fd.crt \
    -certfile fd-chain.crt
Enter Export Password: ****************
Verifying - Enter Export Password: ****************

$ openssl pkcs12 -in fd.p12 -out fd.pem -nodes

Bag Attributes
    localKeyID: E3 11 E4 F1 2C ED 11 66 41 1B B8 83 35 D2 DD 07 FC DE 28 76
subject=/1.3.6.1.4.1.311.60.2.1.3=GB/2.5.4.15=Private Organization/serialNumber=06694169↩
/C=GB/ST=London/L=London/O=Feisty Duck Ltd/CN=www.feistyduck.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http:/↩
/certificates.starfieldtech.com/repository/CN=Starfield Secure Certification Authority
-----BEGIN CERTIFICATE-----
MIIF5zCCBM+gAwIBAgIHBG9JXlv9vTANBgkqhkiG9w0BAQUFADCB3DELMAkGA1UE
BhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxJTAj
[...]

$ openssl pkcs12 -in fd.p12 -nocerts -out fd.key -nodes
$ openssl pkcs12 -in fd.p12 -nokeys -clcerts -out fd.crt
$ openssl pkcs12 -in fd.p12 -nokeys -cacerts -out fd-chain.crt

$ openssl crl2pkcs7 -nocrl -out fd.p7b -certfile fd.crt -certfile fd-chain.crt

openssl pkcs7 -in fd.p7b -print_certs -out fd.pem

Let’s start this deep dive by first determining which suites are supported by your OpenSSL installation. To do this, invoke the ciphers command with the -v switch and ALL:COMPLEMENTOFALL as a parameter:

$ openssl ciphers -v 'ALL:COMPLEMENTOFALL'

At this point you will observe a lot of output, consisting of everything your installation of OpenSSL has to offer. In my case, there were 162 suites in the output. Let’s take a look at one line:

TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD

Each line of output provides extended information on one suite. From left to right:

Traditionally, OpenSSL didn’t use official suite names, although it does now for TLS 1.3 suites. As of recently, when you add the -stdname switch to the ciphers tool, you’ll get the official suite names and OpenSSL names at the same time.

In the previous section, we discussed how to get a complete list of supported suites—but that list is deceptive. Just because something is supported doesn’t mean it’s going to be enabled. Unless you tell it otherwise, the ciphers command outputs even the suites that will not be allowed. The trick is to use the -s switch, after which the number of suites will go down from 162 to only 77.

Granted, the reduction is in large part due to the removal of PSK and SRP suites, which removes 66 entries (down to 96). The remaining difference of 21 entries is due to the concept called security level, which OpenSSL now uses.16

Cipher suite configuration is complex, and most people are not experts in cryptography. For example, it’s very easy to follow some outdated advice from the Internet and add an insecure element to your configuration. Additionally, there are some aspects of security that cannot be configured via cipher suites and previously couldn’t be controlled at all. Security levels therefore are designed to guarantee minimum security requirements, even if incorrect configuration is requested. They are a very useful safety net.

The most important aspect of security levels is knowing what not to use, and that’s the first two levels. Level 0 imposes no restrictions and is potentially insecure (depending on what features were enabled at compile time). You aren’t very likely to need this level in practice. Level 1 is slightly better but still allows weak elements. You may need this level for interoperability purposes with legacy systems. Level 1 is the default security level in OpenSSL.

In practice, you should aim to use level 2 as your baseline. This level supports 2048-bit RSA keys, which most web sites use today. Weak protocols such as SSL 2 and SSL 3 won’t be allowed, along with RC4 and SHA1. If you’re not using stock OpenSSL, you may find that your distribution already made this choice for you; for example, Ubuntu 20.04 LTS chooses level 2 as the default.

Levels 3 and up are levels you should consider if you have specific security requirements and want to enforce stronger encryption. For example, if you enable level 3, 2048-bit RSA keys won’t be allowed. Because keys stronger than this are quite slow, this choice of security level implicitly restricts you to ECDSA keys.

You can gain a better understanding of security levels by using the -s switch along with the @SECLEVEL keyword as part of your suite configuration. For an example, let’s see how the switch from level 3 to level 4 affects one arbitrary suite configuration. At level 3, there are four suites in the output:

$ openssl ciphers -v -s -tls1_2 'EECDH+AESGCM @SECLEVEL=3'
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384   TLSv1.2 Kx=ECDH Au=RSA   Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256   TLSv1.2 Kx=ECDH Au=RSA   Enc=AESGCM(128) Mac=AEAD

However, at level 4 there are only two suites in the output, because the 128-bit suites were removed:

$ openssl ciphers -v -s -tls1_2 'EECDH+AESGCM @SECLEVEL=4'
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384   TLSv1.2 Kx=ECDH Au=RSA   Enc=AESGCM(256) Mac=AEAD

You may have noticed that the previous example introduces the -tls1_2 switch, which outputs only suites that can be negotiated with TLS 1.2. This switch, along with -tls1_3, -tls1_1, -tls1, and -ssl3, is very useful for removing unwanted output when you’re interested in only one protocol.

If you’re working with the ciphers tool and you’re not familiar with how TLS 1.3 is configured (e.g., you only worked with versions of OpenSSL that did not support this protocol), you may be confused by the fact that no matter what configuration you specify, the TLS 1.3 suites are always listed at the top. This is happening because OpenSSL introduced a separate mechanism for TLS 1.3 suite configuration. At the library level, there are separate function calls for this, and there is a separate approach to use with the command-line tools.

When it comes to the ciphers tool, to control TLS 1.3 suites you’ll need to use the -ciphersuites switch. To illustrate this, let’s enable one TLS 1.3 suite and one SEED suite:

$ openssl ciphers -v -s -ciphersuites TLS_AES_256_GCM_SHA384 SEED-SHA
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
SEED-SHA                SSLv3   Kx=RSA Au=RSA Enc=SEED(128)   Mac=SHA1

When they were adding this new configuration mechanism for TLS 1.3, OpenSSL developers took an opportunity to simplify how suites are configured by removing a variety of tools and keywords that can now be called legacy suite configuration. The only supported approach for TLS 1.3 is to provide a colon-separated list of the suites you wish to support, in the order you wish to support them. That’s all. For example:

$ openssl ciphers -v -s -tls1_3 \
-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD

How does this new approach to TLS 1.3 configuration affect real life? Depending on your tools, you may now find yourself needing to use two configuration strings where previously there was only one. In the Apache web server, the SSLCipherSuite directive has been extended with an optional first parameter, enabling you to target the protocols you wish to configure. So you could do something like this:

SSLCipherSuite TLSv1.3 TLS_AES_128_GCM_SHA256
SSLCipherSuite EECDH+AES128+AESGCM

The result would be equivalent to the following:

TLS_AES_128_GCM_SHA256         TLSv1.3 Kx=any  Au=any   Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2 Kx=ECDH Au=RSA   Enc=AESGCM(128) Mac=AEAD

Not all tools have added support for TLS 1.3 suite configuration. If you prefer the Nginx web server, for example, you’ll find that there is no official way to change the TLS 1.3 defaults. Instead, you’ll always get the OpenSSL defaults. For most users, this not yet a real problem because all TLS 1.3 suites are strong. But if you want to do something out of the ordinary, perhaps enable the CCM suites that are currently disabled by default, you’ll have to resort to using a workaround by changing the OpenSSL defaults via a configuration file, which I will cover in the next section.

Occasionally, you’ll run into a problem trying to configure some applications to use OpenSSL in a certain way, only to be frustrated if there are no configuration options to achieve what you need. In that situation, you can resort to changing the OpenSSL defaults.

On startup, OpenSSL will go through an initialization procedure that attempts to fetch the defaults from the filesystem. This procedure consists of the following steps:

This process ensures that there are a number of options available to control the defaults in a way that solves a particular need. We can change the default configuration of only one program or of all programs that run on the same server.

For the latter use case, use the version tool to determine the location of the default configuration file:

$ openssl version -d
OPENSSLDIR: "/usr/lib/ssl"

Now that we know how to change the defaults, the question instead becomes what to put into the configuration file. For the syntax of configuration files and detailed information, it’s best that you consult the official documentation.17 However, if you just need to reconfigure the cipher suite configuration, take a look at the following example that does just that:

[default_conf]
ssl_conf = ssl_section

[ssl_section]
system_default = system_default_section

[system_default_section]
MinProtocol = TLSv1.2
CipherString = DEFAULT:@SECLEVEL=2
Ciphersuites = TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256
Options = ServerPreference,PrioritizeChaCha

This configuration file specifies the minimum supported protocol, security level, legacy cipher suite configuration, and TLS 1.3 suite configuration, and it also enables special ChaCha20 prioritization, which is triggered if OpenSSL detects that client prefers this cipher over AES. For the complete list of available parameters, refer to the official documentation.18

When it comes to cipher suite configuration, the best approach is to avoid legacy keyword-based suite configuration and instead explicitly specify the suites you want to use. By doing this, you don’t have to learn about complex keyword behavior, you’ll minimize mistakes, and you’ll also leave behind a configuration that is self-documenting and easy to understand.

In this section, I will give you my recommendations and explain my reasoning. For simplicity, I’ll show the suites as a single ordered list, even though they are configured separately for TLS 1.3 and separately for earlier protocol versions. Here is my recommended default configuration for all TLS services, given as a list of suites in the order of preference:

TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_256_GCM_SHA384

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-CHACHA20-POLY1305
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256

This configuration uses only suites that support forward secrecy and provide strong encryption.19 The preference is for 128-bit suites, which are faster and provide strong security; ECDSA public key encryption, which is faster and more secure than the traditional RSA (at the usual key lengths); ECDHE key exchange, which is faster than DHE; and authenticated encryption, which is faster and more secure than the old CBC mode.

It’s possible to have a shorter suite configuration—for example, by removing the 256-bit suites, as well as those that use DHE for the key exchange. However, I have found that having a somewhat diverse collection of suites helps avoid various edge cases with picky clients.

In terms of interoperability, all modern browsers and clients should be able to connect. Some very old clients might not, but we’re talking about obsolete platforms—for example, Internet Explorer running on Windows XP. If you really need to support this, you will need to append to the list suites that use obsolete features such as 3DES or the RSA key exchange.

Finally, when it comes to performance, there is one final trick you can employ: tell OpenSSL to use ChaCha20 with clients that prefer this cipher over AES. You will notice that in my configuration, there is always a ChaCha20 suite that follows a 128-bit AES-GCM suite. For most clients, AES-GCM is the right choice, but ChaCha20 is a better option for some mobile clients because they can do it faster.20 With ChaCha20 prioritization, you can give those mobile clients a better experience (faster loading times).

The OpenSSL option for this is called PrioritizeChaCha. This feature is a relatively new configuration option, and you will find that not all server software can control it. For example, at the time of writing, Apache can (using SSLOpenSSLConfCmd) but Nginx can’t. Resorting to changing the OpenSSL defaults, as described in the previous section, should do the trick in the latter situation.

The DH key exchange has fallen out of fashion, but you may still want to support it in your servers on philosophical grounds. If you do, you may find with some server software (e.g., Nginx) that you need to manually configure the desired DH parameters. This is how:

$ openssl dhparam -out dh-2048.pem 2048

In practice, only 2048-bit DH parameters make sense. Anything less is going to be weak or insecure, while anything more is going to slow you down. DH parameters need not be secret. In fact, there are some predefined groups (sometimes called well-known groups) that are recommended because they are known to have been securely generated.21

Rarely, you may encounter a situation, usually in a legacy environment, in which you need to configure a server with 1024-bit DH parameters. It’s essential that you don’t use a well-known group in this case. The issue is that weak DH groups are susceptible to precomputation attacks, which further downgrade their security. If you really must use a 1024-bit DH parameters, always generate your own unique group using OpenSSL.

In this section, I’ll briefly cover the legacy keyword-based configuration of cipher suites that applies to TLS 1.2 and earlier protocol versions. This section is important largely only if you’re interested in how the keyword approach works. Otherwise, you’re better off simply specifying the suites you wish to use, as I did with the recommended configuration in the previous section.

$ openssl ciphers -v -s -tls1_2 'EECDH+AESGCM'
ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2 Kx=ECDH Au=RSA   Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2 Kx=ECDH Au=RSA   Enc=AESGCM(128) Mac=AEAD

$ openssl ciphers -v 'ECDHE:DHE'

$ openssl ciphers -v 'ECDHE DHE'

$ openssl ciphers -v '@HIGH'
Error in cipher list
140460843755168:error:140E6118:SSL routines:SSL_CIPHER_PROCESS_RULESTR:invalid ↩
command:ssl_ciph.c:1317:

$ openssl ciphers -v 'SHA512'
Error in cipher list
140202299557536:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:ssl↩
_lib.c:1312:

In the rest of this section, we’re going to create a private CA that’s similar in structure to public CAs. There’s going to be one root CA from which other subordinate CAs can be created. We’ll provide revocation information via CRLs and OCSP responders. To keep the root CA offline, OCSP responders are going to have their own identities. This isn’t the simplest private CA you could have, but it’s one that can be secured properly. As a bonus, the subordinate CA will be technically constrained, which means that it will be allowed to issue certificates only for the allowed hostnames.

After the setup is complete, the root certificate will have to be securely distributed to all intended clients. Once the root is in place, you can begin issuing client and server certificates. The main limitation of this setup is that the OCSP responder is chiefly designed for testing and can be used only for lighter loads.

Creating a new CA involves several steps: configuration, creation of a directory structure and initialization of the key files, and finally generation of the root key and certificate. This section describes the process as well as the common CA operations.

[default]
name                    = root-ca
domain_suffix           = example.com
aia_url                 = http://$name.$domain_suffix/$name.crt
crl_url                 = http://$name.$domain_suffix/$name.crl
ocsp_url                = http://ocsp.$name.$domain_suffix:9080
default_ca              = ca_default
name_opt                = utf8,esc_ctrl,multiline,lname,align

[ca_dn]
countryName             = "GB"
organizationName        = "Example"
commonName              = "Root CA"

[ca_default]
home                    = .
database                = $home/db/index
serial                  = $home/db/serial
crlnumber               = $home/db/crlnumber
certificate             = $home/$name.crt
private_key             = $home/private/$name.key
RANDFILE                = $home/private/random
new_certs_dir           = $home/certs
unique_subject          = no
copy_extensions         = none
default_days            = 3650
default_crl_days        = 365
default_md              = sha256
policy                  = policy_c_o_match

[policy_c_o_match]
countryName             = match
stateOrProvinceName     = optional
organizationName        = match
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[req]
default_bits            = 4096
encrypt_key             = yes
default_md              = sha256
utf8                    = yes
string_mask             = utf8only
prompt                  = no
distinguished_name      = ca_dn
req_extensions          = ca_ext

[ca_ext]
basicConstraints        = critical,CA:true
keyUsage                = critical,keyCertSign,cRLSign
subjectKeyIdentifier    = hash

[sub_ca_ext]
authorityInfoAccess     = @issuer_info
authorityKeyIdentifier  = keyid:always
basicConstraints        = critical,CA:true,pathlen:0
crlDistributionPoints   = @crl_info
extendedKeyUsage        = clientAuth,serverAuth
keyUsage                = critical,keyCertSign,cRLSign
nameConstraints         = @name_constraints
subjectKeyIdentifier    = hash

[crl_info]
URI.0                   = $crl_url

[issuer_info]
caIssuers;URI.0         = $aia_url
OCSP;URI.0              = $ocsp_url

[name_constraints]
permitted;DNS.0=example.com
permitted;DNS.1=example.org
excluded;IP.0=0.0.0.0/0.0.0.0
excluded;IP.1=0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0

[ocsp_ext]
authorityKeyIdentifier  = keyid:always
basicConstraints        = critical,CA:false
extendedKeyUsage        = OCSPSigning
keyUsage                = critical,digitalSignature
subjectKeyIdentifier    = hash

$ mkdir root-ca
$ cd root-ca
$ mkdir certs db private
$ chmod 700 private
$ touch db/index
$ openssl rand -hex 16  > db/serial
$ echo 1001 > db/crlnumber

$ openssl req -new \
    -config root-ca.conf \
    -out root-ca.csr \
    -keyout private/root-ca.key

$ openssl ca -selfsign \
    -config root-ca.conf \
    -in root-ca.csr \
    -out root-ca.crt \
    -extensions ca_ext

V    240706115345Z        1001    unknown    /C=GB/O=Example/CN=Root CA

$ openssl ca -gencrl \
    -config root-ca.conf \
    -out root-ca.crl

$ openssl ca \
    -config root-ca.conf \
    -in sub-ca.csr \
    -out sub-ca.crt \
    -extensions sub_ca_ext

$ openssl ca \
    -config root-ca.conf \
    -revoke certs/1002.pem \
    -crl_reason keyCompromise

$ openssl req -new \
    -newkey rsa:2048 \
    -subj "/C=GB/O=Example/CN=OCSP Root Responder" \
    -keyout private/root-ocsp.key \
    -out root-ocsp.csr

$ openssl ca \
    -config root-ca.conf \
    -in root-ocsp.csr \
    -out root-ocsp.crt \
    -extensions ocsp_ext \
    -days 30

$ openssl ocsp \
    -port 9080
    -index db/index \
    -rsigner root-ocsp.crt \
    -rkey private/root-ocsp.key \
    -CA root-ca.crt \
    -text

$ openssl ocsp \
    -issuer root-ca.crt \
    -CAfile root-ca.crt \
    -cert root-ocsp.crt \
    -url http://127.0.0.1:9080

Response verify OK
root-ocsp.crt: good
        This Update: Jul  9 18:45:34 2014 GMT

The process of subordinate CA generation largely mirrors the root CA process. In this section, I will only highlight the differences where appropriate. For everything else, refer to the previous section.

[default]
name                    = sub-ca
ocsp_url                = http://ocsp.$name.$domain_suffix:9081

[ca_dn]
countryName             = "GB"
organizationName        = "Example"
commonName              = "Sub CA"

[ca_default]
default_days            = 365
default_crl_days        = 30
copy_extensions         = copy

[server_ext]
authorityInfoAccess     = @issuer_info
authorityKeyIdentifier  = keyid:always
basicConstraints        = critical,CA:false
crlDistributionPoints   = @crl_info
extendedKeyUsage        = clientAuth,serverAuth
keyUsage                = critical,digitalSignature,keyEncipherment
subjectKeyIdentifier    = hash

[client_ext]
authorityInfoAccess     = @issuer_info
authorityKeyIdentifier  = keyid:always
basicConstraints        = critical,CA:false
crlDistributionPoints   = @crl_info
extendedKeyUsage        = clientAuth
keyUsage                = critical,digitalSignature
subjectKeyIdentifier    = hash

$ openssl req -new \
    -config sub-ca.conf \
    -out sub-ca.csr \
    -keyout private/sub-ca.key

$ openssl ca \
    -config root-ca.conf \
    -in sub-ca.csr \
    -out sub-ca.crt \
    -extensions sub_ca_ext

$ openssl ca \
    -config sub-ca.conf \
    -in server.csr \
    -out server.crt \
    -extensions server_ext

$ openssl ca \
    -config sub-ca.conf \
    -in client.csr \
    -out client.crt \
    -extensions client_ext