Internal CA instead of Self-Signed Certificates

February 8, 2020 | Posted in certificates,security

TLS/SSL has become a de-facto protocol even for development and internal APIs.
Many projects resort to self-signed/self-generated certificates. These certificates, however, have a large downside. It's difficult to frequently refresh them since all the clients would have to update them at the same time so that they remain trusted.

To minimize the effort, self-signed certificates are often issued for several years, which, of course. compromises security.

An internal Certificate Authority can be used instead to avoid the issue of updating expired self-signed end certificates.

An internal CA can be issued for multiple years, so there is no need for frequent updates across all clients.

An internal CA is really not much different from an "official" CAs like DigiCert. DigiCert would simply verify domain ownership before signing the certificate request. Once this is done, it simply signs our certificate request thus creating a valid X.509 cert. The signature (usually using SHA256WITHRSA) is stored in a separate field in the X.509 cert as defined in rfc5280.

If needed, an internal CA could conduct a more in-depth verification of the request, including obtaining information on what kind of service the new certificate will be used for.

It can also mandate various extensions on key usage thus making the cert more secure. Of course, certificate duration can be reduced to six months or less; there is really no reason why a certificate should be valid for 12 months.

Establishing a CA-level trust is convenient, however, it also requires to have a revocation process in place. This process could be based on good old CRL or OCSP.

You have to have an ability to revoke a compromised cert, otherwise, the certificate and its private key can be used for nefarious purposes if the server is compromised.

There are many ways to implement OCSP/CRL, we offer a mechanism built into our DPBuddy/SecScan product.

Please make sure to properly guard the private key of the internal CA. It has to be stored separately from the X.509 cert or from any other certificates since it allows us to issue a cert for any internal domain.

The X.509 counterpart of the internal CA, on the other hand, should be freely distributed to all trust stores of all the components of the system as well as to the browsers of the end-users of the application.

You you can use openssl CA command to sign internal CSRs thus becoming your own certificate authority.