OpenSSL Certificates

Created: February 02, 2020

To do:

Issuing certs
Revoking certs

Generating CSRs With a SAN Using a `.cnf` File

cert_config.cnf:

[ req ]
default_bits       = 2048 # RSA only
distinguished_name = req_distinguished_name
req_extensions     = req_ext
prompt = no

[ req_distinguished_name ]
countryName                 = 
stateOrProvinceName         = 
localityName               = 
organizationName           = 
commonName                 = 

[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1   = domain1.com
DNS.2   = domain2.com

RSA:

openssl req -out cert_req.csr -newkey rsa:{2048|4096} -nodes \
	-keyout private.pem -config cert_config.cnf 

ECDSA with P-256:

openssl ecparam -out private.pem -name prime256v1 -genkey
openssl req -new -sha256 -key private.pem -nodes -out cert_req.csr \
	-config cert_config.cnf

ECDSA with P-256 is currently recommended in 2020.
As of 2020, ED25519 is not supported by browsers for TLS.

ED25519:

openssl genpkey -algorithm Ed25519 -out private.pem
openssl req -new -key private.pem -out cert_req.csr -nodes \
	-config cert_config.cnf

nodes: don’t encrypt the private key.

Verify CSR Fields

openssl req -noout -text -in cert_req.csr

Generate CSR From an Existing Certificate and Private Key

openssl x509 -in cert.crt -signkey private.pem -x509toreq -out cert_req.csr

Self-Signed Certificate Generation

openssl x509 -signkey private.pem -in cert_req.csr -req -days 365 -out cert.crt

View Certificate Fields

openssl x509 -text -noout -in cert.crt

Verify a Certificate was Signed by a Specific CA

openssl verify -verbose -CAFile ca.crt cert.crt

Verify a Private Key Matches a Certificate and CSR

openssl rsa -noout -modulus -in domain.key | openssl md5
openssl x509 -noout -modulus -in domain.crt | openssl md5
openssl req -noout -modulus -in domain.csr | openssl md5

Create DER CRL

openssl crl \
    -in crl/signing-ca.crl \
    -out crl/signing-ca.crl \
    -outform der

CRLs must be in DER format.

Convert PEM to PKCS7

openssl crl2pkcs7 -nocrl \
       -certfile signing.crt \
       -certfile root.crt \
       -out domain.p7b \
       -outform der

Create PKCS#12 bundle

openssl pkcs12 -export \
    -name "Fred Flintstone" \
    -inkey certs/fred.key \
    -in certs/fred.crt \
    -out certs/fred.p12

PKCS#12 is used to bundle a certificate and its private key. Additional certificates may be added, typically the certificates comprising the chain up to the Root CA.

Create PEM bundle

PEM bundles are created by concatenating other PEM-formatted files. The most common forms are “cert chain”, “key + cert”, and “key + cert chain”. PEM bundles are supported by OpenSSL and most software based on it (e.g. Apache mod_ssl and stunnel.)
A PEM bundle is an aggregation of the root CAs public PEM files and any intermediate CAs public PEM files.
openssl verify -verbose -CAFile ca.crt cert.crt: can be used to verify order.
Intermediate CAs can be included:

openssl verify -CAfile ca.pem \
                 -untrusted intermediate.cert.pem \
                 cert.pem
cert.pem: OK

cat cert.pem intermediate.pem > chain.pem: implement the chain.
Verification:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout

Expected output:

subject: server certificate file subject (usually FQDN) issuer: intermediate CA name. subject: intermediate CA name. issuer: root CA name

Encodings (also used as file extensions)

.DER: a binary DER encoded certificate.
.PEM: ASCII (Base64) armored data, prefixed with:

—–BEGIN CERTIFICATE—–

File Extensions

.CRT: default extension for certificates.

Contents either DER or PEM encoded.
.CER: Microsoft alternative to .CRT.

Contents either DER or PEM encoded.
.KEY: typically a PKCS#8 encapsulated private key.

Contents either DER or PEM encoded.
.CRT and .CER are interchangeable if the encodings are the same.

Encoding Conversion

openssl x509 -in {FILE_IN}.crt -outform der -out {FILE_OUT}.der

PEM to DER.
openssl x509 -in {FILE_IN}.crt -inform der -outform pem -out {FILE_OUT}.pem

DER to PEM.

Certification Management Strategies

Defining operational and security policies; identifying roles and responsibilities.
Establishing comprehensive certificate inventories and ownership tracking.
Conducting continuous monitoring of certificate operational and security status.
Automating certificate management to minimize human error and maximize efficiency on a large scale.
Enabling rapid migration to new certificates and keys when cryptographic mechanisms are found to be weak, compromised or vulnerable.
Source: https://www.nccoe.nist.gov/projects/building-blocks/ tls-server-certificate-management

Certification Authority Authorization (CAA)

RFC 6844

CAA lets the owner of a domain name authorize designated and specific Certification Authorities (CAs) to issue SSL certificates for their domain name.
CAA Records are a new type of DNS record.
Syntax: domain.com. CAA {0|1} issue "ca.com"
Also allows certs to be issued for subdomains of domain.com, including wildcards.
Multiple records can exist to allow multiple CAs.
The number is meant to signify whether the following tag/value pair are critical and must be understood by the CA. 1 means it must be understood. For the moment, 0 seems to be the standard. In the future 0 - 255 will be supported.
domain.com. CAA 0 issue ";": don’t allow any CA.
issuewild takes precedence over issue and can be used to define which CAs can issue wildcard certs.

Ex:
```
domain.com.    CAA 0 issue "ca.com"
domain.com.    CAA 0 issuewild ";"
```
Allow ca.com to issue certs but deny wildcard certs.

If issue is blocked, a valid CA in issuewild will still allow a wildcard cert to be issued.
iodef can be used to report invalid certificate requests to the domain owner.
```
domain.com.    CAA 0 iodef "mailto:report@domain.com"
domain.com.    CAA 0 iodef "report.domain.com"
```
Either or both of these options can be used.

The latter option will post an IODEF report to report.domain.com. IODEF can read by some SIEM products. IODEF is described in RFC 6546.

Certificate Revocation

Online Certificate Status Protocol (OCSP) is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate.
OCSP is a request/reponse protocol that usually works over HTTP.
A client sends a query to an OCSP server. A signed response is sent to the client. On the client, the response is verified using the public key.
Unfortunately, browsers, especially Chrome, do not support OCSP. Supposedly for performance reasons.
There is also an older system called Certicate Revocation Lists (CRLs).
OCSP Stapling is a new method, designed to improve OCSP performance, that allows web servers to obtain signed OCSP responses for their certificates that can be cached for up to 7 days.
Servers include the cached OCSP response in their HTTPS responses.
The client does not know whether the server supports stapling or not, therefore it is vulnerable to MITM attacks.
OCSP Must-Staple was then created to force stapling, and therefore solve this problem. It involves enabling this extension when a cert is created, and configuring the web server appropriately.
[ v3_req ] is optional section in an .cnf file that is created by adding req_extensions = v3_req to the [req] section.
To enable the Must-Staple extension, at the bottom of the [ v3_req ] section in a .cnf file, add a line:

1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05

For OpenSSL 1.1.0 or higher there is the following alternative:

tlsfeature = status_request
To verify, use SSL labs or: openssl x509 -in {FILE}.crt -noout -text. We’re looking for a line with 1.3.6…

To enable OCSP stapling in Apache:

# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling          on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache        shmcb:/var/run/ocsp(128000)

To enable OCSP stapling in Nginx:

# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;