How to properly setup openssl CA to generate ssl client certificates

Solution 1:

You're right to be concerned about "CRL signing", "Any Purpose CA", and "OCSP Helper", these are usually reserved for CA certificates or certificates specifically issued for signing certificate revocation lists (CRLs, a list of certificates that are invalid), or running an OCSP server (similar to CRLs, but an online service that provides validity status for certificates).

The relevant OpenSSL documentation page is for the x509 command and x509v3_config

Here's the OpenSSL configuration I use for generating client certificates:

[user]
basicConstraints = critical,CA:FALSE
extendedKeyUsage = clientAuth,emailProtection
subjectAltName=email:copy
crlDistributionPoints = URI:http://www.rgweb.org/ca/rgweb-ca.crl
authorityKeyIdentifier=keyid:always
authorityInfoAccess = caIssuers;URI:http://www.rgweb.org/ca/rgweb-ca.cer

I'll take you through it line-by-line:

The basicConstraints is set as critical, which means "reject this certificate if you don't understand this bit", and specifies that the certificate is not a CA. Even if someone uses software to issue a certificate from this certificate, it won't ever be trusted.

The extended key usage is not essential, but some software requires it be present and have a particular purpose listed. This lists client authentication (what you're talking about) and also S/MIME email signing & encryption; you can safely remove the S/MIME purpose if you don't need it.

subjectAltName allows you to include information about the subject that you can't include in the subject field. It's also used in web server certificates to include domain names that the certificate may be used for other than the domain specified in the subject's common name attribute; these certificates are referred to as SAN (subject alternative name) certificates. It's common practice to include the email address in the subjectAltName rather than in the subject; you don't have to include an email address at all, and can omit the extension.

crlDistributionPoints lists the places that the CRL for the issuing authority is available; it tells software that's trying to validate the certificate "here's where to go to see if this certificate is still valid." For Internet use, a http:// URL is probably best (CRLs are digitally signed, so there's no need for https, and it may cause trust loop issues).

authorityKeyIdentifier is usually the SHA-1 hash of the issuing CA's public key (though it may be other values). If you include this extension, the value must match the value of subjectKeyIdentifier in the issuing CA certificate.

authorityInfoAccess is a bit like crlDistributionPoints but it specifies where to get the issuing CA certificate rather than the CRL. This is useful if you have a long chain of trust: e.g. CA-1 issues CA-2, which issues CA-3, which issues the certificate; software attempting to verify the certificate can use this extension to get the CA-3 certificate, then use the value in that certificate to get the CA-2 certificate, etc. Usually, the certificate chain (in this case, the CA-2 certificate and CA-3 certificate) is bundled alongside the subject's certificate (e.g. in an SSL transaction, or S/MIME email). I don't know of any software that uses this extension, but I don't know that it's not commonly used, either. It's commonly included in certificates.

Of all that, you only really need the basicConstraints and extendedKeyUsage; basic constraints really, really must be critical (or you've just handed out CA certificates!), and extended key usage generally isn't.