A public key’s size and its algorithm is usually the first thing we see when we look at the “Public Key Info” section of an x.509 certificate.

Can we evaluate security of a website or a digital signature based on its public key without any access to the private key?

Turns out that we can, at least, to a degree.

First, we need to understand that it’s the combination of the algorithm and the key size that defines the “strength” of the key. The most widely used public-key algorithm today is RSA. Elliptic Curve (EC) algorithms (that are truly superior to RSA) are quickly gaining ground and taking the second place.

Read the rest of this post »

When you create certificates or certificate requests for a CA, your certificate must comply with certain standards, otherwise, it will be considered “non-standard”.

On mac os you even get a warning that a website presents a non-standard certificate when you try to open the cert in Safari or Chrome (but not in Firefox).

First of all, you must have the Subject Alternative Name (SAN) extension, this extension must contain DNS names of all the domain names the certificate was issued for. Browsers no longer trust the “CN” of the subject field.

Your certificate must have a “Basic Constraints” extension marked as critical and specifying that the subject is not a CA.

Your certificate must also have a non-critical “Extended key usage” extension specifying “TLS Web Server Authentication” (if your certificate is used by a server).

Another requirement is to provide a “Key Usage” extension (marked as critical) allowing for “Digital Signature” and “Key Encipherment”.

Finally, and this is just common sense, your certificate’s validity must be limited to 825 days (the shorter the better) and the RSA’s minimal acceptable key length is 2048.

First, create your own internal CA.
You can use excellent Keystore Explorer tool for that and all the subsequent actions; feel free to translate it to OpenSSL commands.

Internal CA is really just a self-signed cert (keypair). Make sure to use proper extensions when creating it. At the very least, specify “Subject is a CA” in “Basic Constraints”.

Do not set CN in the subject so this keypair can never be used as a cert for actual domains.

CAs are allowed to have a long validity period, remember that you will need to reissue all the certs once the CA’s cert expires. However, we recommend limiting it to 5 years since you’d want to automate your cert provisioning anyway.

Keep your internal CA keypair in a separate keystore (Java) or in a completely separate place (ideally, in your centralized secrets/key manager). Never place the CA’s key in the same keystore with the certificate issued by this CA. Of course, the X509 of the CA could be widely distributed.

You can now start generating end-entity certs.

Create a new keypair (a self-signed cert) in the Keystore Explorer.

Your cert must have certain extensions, otherwise, it will be considered invalid, especially by mac OS browsers.

At the very minimum, it must include “Basic Constraints”, “Extended Key Usage”, “Key Usage”, “Subject Alternative Name” with the DNS names of your (internal) domains.

Note that browsers no longer trust the “CN” field and the “Subject Alternative Name” extension is a must.

Read the rest of this post »

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 would 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.

Read the rest of this post »

Self-signed certificates are widely used for testing/development and sometimes in production for internal websites.

Self-signed certificates are created without any CA, thus they don’t have a parent. The issuer is also the subject of the certificate.

In general, the use of self-signed certificates must be discouraged as they present an inherent security risk. For example, there is no way to revoke a self-signed cert. Using an internal CA for issuing all internal certificates is a much better option, we will cover it in a future post. It is also difficult to manage self-signed certificates — imagine refreshing trust stores of all client components when a self-signed cert is extended.

Self-signed certs come at a substantial maintenance cost — issuing a cert for a long period of time is insecure, but the short validity adds to the certificate renewal/distribution overhead.

The following best practices will help to make self-signed and internally-issued certificates more secure:

Read the rest of this post »

Certificate validation errors are a frequent cause of issues when dealing with APIs and Web services calls, especially when self-signed certificates are used.
The error message is usually javax.net.ssl.SSLHandshakeException: PKIX path building failed.

How to Troubleshoot

Read the rest of this post »