Create Certifying Authority
Create Certifying Authority
Typically, the root CA does not sign server or client certificates directly. The root
CA is only ever used to create one or more intermediate CAs, which are trusted
by the root CA to sign certificates on their behalf. This is best practice. It allows
the root key to be kept offline and unused as much as possible, as any
compromise of the root key is disastrous.
Note
It’s best practice to create the root pair in a secure environment. Ideally, this
should be on a fully encrypted, air gapped computer that is permanently isolated
from the Internet. Remove the wireless card and fill the ethernet port with glue.
# mkdir /root/ca
Create the directory structure. The index.txt and serial files act as a kind of flat
file database to keep track of signed certificates.
# cd /root/ca
# mkdir certs crl newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
The [ ca ] section is mandatory. Here we tell OpenSSL to use the options from
the [ CA_default ] section.
[ ca ]
# `man ca`
default_ca = CA_default
The [ CA_default ] section contains a range of defaults. Make sure you declare
the directory you chose earlier ( /root/ca ).
[ CA_default ]
# Directory and file locations.
dir = /root/ca
certs = $dir/certs
crl_dir = $dir/crl
new_certs_dir = $dir/newcerts
database = $dir/index.txt
serial = $dir/serial
RANDFILE = $dir/private/.rand
We’ll apply policy_strict for all root CA signatures, as the root CA is only being
used to create intermediate CAs.
[ policy_strict ]
# The root CA should only sign intermediate certificates that match.
# See the POLICY FORMAT section of `man ca`.
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ policy_loose ]
# Allow the intermediate CA to sign a more diverse range of certificates.
# See the POLICY FORMAT section of the `ca` man page.
countryName = optional
stateOrProvinceName = optional
localityName = optional
organizationName = optional
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
Options from the [ req ] section are applied when creating certificates or
certificate signing requests.
[ req ]
# Options for the `req` tool (`man req`).
default_bits = 2048
distinguished_name = req_distinguished_name
string_mask = utf8only
[ req_distinguished_name ]
# See <https://en.wikipedia.org/wiki/Certificate_signing_request>.
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
0.organizationName = Organization Name
organizationalUnitName = Organizational Unit Name
commonName = Common Name
emailAddress = Email Address
The next few sections are extensions that can be applied when signing
certificates. For example, passing the -extensions v3_ca command-line argument
will apply the options set in [ v3_ca ] .
We’ll apply the v3_ca extension when we create the root certificate.
[ v3_ca ]
# Extensions for a typical CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
[ v3_intermediate_ca ]
# Extensions for a typical intermediate CA (`man x509v3_config`).
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
We’ll apply the usr_cert extension when signing client certificates, such as those
used for remote user authentication.
[ usr_cert ]
# Extensions for client certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, email
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, emailProtection
We’ll apply the server_cert extension when signing server certificates, such as
those used for web servers.
[ server_cert ]
# Extensions for server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
[ crl_ext ]
# Extension for CRLs (`man x509v3_config`).
authorityKeyIdentifier=keyid:always
We’ll apply the ocsp extension when signing the Online Certificate Status
Protocol (OCSP) certificate.
[ ocsp ]
# Extension for OCSP signing certificates (`man ocsp`).
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, OCSPSigning
Note
Use 4096 bits for all root and intermediate certificate authority keys. You’ll still be
able to sign server and client certificates of a shorter length.
# cd /root/ca
# openssl genrsa -aes256 -out private/ca.key.pem 4096
Warning
Whenever you use the req tool, you must specify a configuration file to use with
the -config option, otherwise OpenSSL will default to /etc/pki/tls/openssl.cnf .
# cd /root/ca
# openssl req -config openssl.cnf \
-key private/ca.key.pem \
-new -x509 -days 7300 -sha256 -extensions v3_ca \
-out certs/ca.cert.pem
The Issuer and Subject are identical as the certificate is self-signed. Note that all
root certificates are self-signed.
The output also shows the X509v3 extensions. We applied the v3_ca extension,
so the options from [ v3_ca ] should be reflected in the output.
X509v3 extensions:
X509v3 Subject Key Identifier:
38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31
X509v3 Authority Key Identifier:
keyid:38:58:29:2F:6B:57:79:4F:39:FD:32:35:60:74:92:60:6E:E8:2A:31
The purpose of using an intermediate CA is primarily for security. The root key
can be kept offline and used as little as possible. If the intermediate key is
compromised, the root CA can revoke the intermediate certificate and create a
new intermediate cryptographic pair.
# mkdir /root/ca/intermediate
Create the same directory structure used for the root CA files. It’s convenient to
also create a csr directory to hold certificate signing requests.
# cd /root/ca/intermediate
# mkdir certs crl csr newcerts private
# chmod 700 private
# touch index.txt
# echo 1000 > serial
[ CA_default ]
dir = /root/ca/intermediate
private_key = $dir/private/intermediate.key.pem
certificate = $dir/certs/intermediate.cert.pem
crl = $dir/crl/intermediate.crl.pem
policy = policy_loose
# cd /root/ca
# openssl genrsa -aes256 \
-out intermediate/private/intermediate.key.pem 4096
Warning
# cd /root/ca
# openssl req -config intermediate/openssl.cnf -new -sha256 \
-key intermediate/private/intermediate.key.pem \
-out intermediate/csr/intermediate.csr.pem
Warning
# cd /root/ca
# openssl ca -config openssl.cnf -extensions v3_intermediate_ca \
-days 3650 -notext -md sha256 \
-in intermediate/csr/intermediate.csr.pem \
-out intermediate/certs/intermediate.cert.pem
The index.txt file is where the OpenSSL ca tool stores the certificate database.
Do not delete or edit this file by hand. It should now contain a line referring to the
intermediate certificate.
Verify the intermediate certificate against the root certificate. An OK indicates that
the chain of trust is intact.
# openssl verify -CAfile certs/ca.cert.pem \
intermediate/certs/intermediate.cert.pem
intermediate.cert.pem: OK
Create this file by concatenating the intermediate and root certificates together.
We will use this file later to verify certificates signed by the intermediate CA.
# cat intermediate/certs/intermediate.cert.pem \
certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem
# chmod 444 intermediate/certs/ca-chain.cert.pem
Note
Our certificate chain file must include the root certificate because no client
application knows about it yet. A better option, particularly if you’re administrating
an intranet, is to install your root certificate on every client that needs to connect.
In that case, the chain file need only contain your intermediate certificate.
The steps below are performed from the perspective of the certificate authority.
However, a third-party can instead create their own private key and certificate
signing request (CSR). They would give the CSR to you, and you would give
back a signed certificate. In that scenario, you can skip
the genrsa and req commands. Note that the third-party doesn’t have to reveal
their private key to you.
14 Create a key
Our root and intermediate pairs are 4096 bits. Since server and client certificates
normally expire after one year, we can safely use 2048 bits instead.
Note
Although 4096 bits is slightly more secure than 2048 bits, it also reduces TLS
handshake speed and significantly increases processor load during handshakes.
For this reason, most websites use 2048-bit pairs.
If you’re creating a cryptographic pair for use with a web server (eg, Apache),
you’ll need to enter this password every time you restart the web server. You
may want to omit the -aes256 option to create a key without a password.
# cd /root/ca
# openssl genrsa -aes256 \
-out intermediate/private/www.example.com.key.pem 2048
# chmod 400 intermediate/private/www.example.com.key.pem
15 Create a certificate
Use the private key to create a certificate signing request (CSR). The CSR
details don’t need to match the intermediate CA. For server certificates,
the Common Name must be a fully qualified domain name (eg, www.example.com ),
whereas for client certificates it can be any unique identifier (eg, e-mail address).
Note that the Common Name cannot be the same as either your root or
intermediate certificate.
# cd /root/ca
# openssl req -config intermediate/openssl.cnf \
-key intermediate/private/www.example.com.key.pem \
-new -sha256 -out intermediate/csr/www.example.com.csr.pem
To create a certificate, use the intermediate CA to sign the CSR. If the certificate
is going to be used on a server, use the server_cert extension. If the certificate is
going to be used for user authentication, use the usr_cert extension. Certificates
are usually given a validity of one year, though a CA will typically give a few days
extra for convenience.
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
-extensions server_cert -days 375 -notext -md sha256 \
-in intermediate/csr/www.example.com.csr.pem \
-out intermediate/certs/www.example.com.cert.pem
# chmod 444 intermediate/certs/www.example.com.cert.pem
The Issuer is the intermediate CA. The Subject refers to the certificate itself.
The output will also show the X509v3 extensions. When creating the certificate,
you used either the server_cert or usr_cert extension. The options from the
corresponding configuration section will be reflected in the output.
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
OpenSSL Generated Server Certificate
X509v3 Subject Key Identifier:
B1:B8:88:48:64:B7:45:52:21:CC:35:37:9E:24:50:EE:AD:58:02:B5
X509v3 Authority Key Identifier:
keyid:69:E8:EC:54:7F:25:23:60:E5:B6:E7:72:61:F1:D4:B9:21:D4:45:E9
DirName:/C=GB/ST=England/O=Alice Ltd/OU=Alice Ltd Certificate
Authority/CN=Alice Ltd Root CA
serial:10:00
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication
Use the CA certificate chain file ( ca-chain.cert.pem ) to verify that the new
certificate has a valid chain of trust.
www.example.com.cert.pem: OK
ca-chain.cert.pem
www.example.com.key.pem
www.example.com.cert.pem
If you’re signing a CSR from a third-party, you don’t have access to their private
key. Therefore you only need to give them back the chain file ( ca-chain.cert.pem )
and the certificate ( www.example.com.cert.pem ).
Note
Some applications vendors have deprecated CRLs and are instead using
the Online Certificate Status Protocol (OCSP).
[ server_cert ]
# ... snipped ...
crlDistributionPoints = URI:http://example.com/intermediate.crl.pem
Note
The CRL OPTIONS section of the ca man page contains more information on how to
create CRLs.
You can check the contents of the CRL with the crl tool.
21 Revoke a certificate
Let’s walk through an example. Alice is running the Apache web server and has
a private folder of heart-meltingly cute cat pictures. Alice wants to grant her
friend, Bob, access to this collection.
$ cd /home/bob
$ openssl genrsa -out [email protected] 2048
$ openssl req -new -key [email protected] \
-out [email protected]
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
-extensions usr_cert -notext -md sha256 \
-in intermediate/csr/[email protected] \
-out intermediate/certs/[email protected]
Sign the certificate? [y/n]: y
1 out of 1 certificate requests certified, commit? [y/n]: y
Alice sends Bob the signed certificate. Bob installs the certificate in his web
browser and is now able to access Alice’s cat pictures. Hurray!
Sadly, it turns out that Bob is misbehaving. Bob has posted Alice’s cat pictures to
Hacker News, claiming that they’re his own and gaining huge popularity. Alice
finds out and needs to revoke his access immediately!
# cd /root/ca
# openssl ca -config intermediate/openssl.cnf \
-revoke intermediate/certs/[email protected]
The line in index.txt that corresponds to Bob’s certificate now begins with the
character R . This means the certificate has been revoked.
In Alice’s case, she can add the SSLCARevocationPath directive to her Apache
configuration and copy the CRL to her web server. The next time that Bob
connects to the web server, Apache will check his client certificate against the
CRL and deny access.
Similarly, OpenVPN has a crl-verify directive so that it can block clients that
have had their certificates revoked.
Full Name:
URI:http://example.com/intermediate.crl.pem
When a CA signs a certificate, they will typically include an OCSP server address
(eg, http://ocsp.example.com ) in the certificate. This is similar in function
to crlDistributionPoints used for CRLs.
Note
It’s recommended to use OCSP instead where possible, though realistically you
will tend to only need OCSP for website certificates. Some web browsers have
deprecated or removed support for CRLs.
[ server_cert ]
# ... snipped ...
authorityInfoAccess = OCSP;URI:http://ocsp.example.com
Create a certificate signing request (CSR). The details should generally match
those of the signing CA, except for the Common Name which must be a fully
qualified domain name.
# cd /root/ca
# openssl req -config intermediate/openssl.cnf -new -sha256 \
-key intermediate/private/ocsp.example.com.key.pem \
-out intermediate/csr/ocsp.example.com.csr.pem
27 Revoke a certificate
The OpenSSL ocsp tool can act as an OCSP responder, but it’s only intended for
testing. Production ready OCSP responders exist, but those are beyond the
scope of this guide.
# cd /root/ca
# openssl genrsa -out intermediate/private/test.example.com.key.pem 2048
# openssl req -config intermediate/openssl.cnf \
-key intermediate/private/test.example.com.key.pem \
-new -sha256 -out intermediate/csr/test.example.com.cert.pem
# openssl ca -config intermediate/openssl.cnf \
-extensions server_cert -days 375 -notext -md sha256 \
-in intermediate/csr/test.example.com.csr.pem \
-out intermediate/cert/test.example.com.cert.pem
Run the OCSP responder on localhost . Rather than storing revocation status in a
separate CRL file, the OCSP responder reads index.txt directly. The response is
signed with the OCSP cryptographic pair (using the -rkey and -rsigner options).
In another terminal, send a query to the OCSP responder. The -cert option
specifies the certificate to query.
As before, run the OCSP responder and on another terminal send a query. This
time, the output shows Cert Status: revoked and a Revocation Time .