Category Archives: security

Public Key Sizes and Their Importance

Posted on: June 14, 2020 | Posted in: Certificates, security

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 »

Mandatory Certificate Extensions

Posted on: May 14, 2020 | Posted in: Certificates, security

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.

The Easiest Way to Issue Certificates Using an Internal CA

Posted on: May 13, 2020 | Posted in: Certificates, security

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 »

Internal CA instead of Self-Signed Certificates

Posted on: 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 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 »

Key File Formats: DER, PEM and PKCS #12 Explained

Posted on: November 26, 2019 | Posted in: Certificates, secrets, security

Public key cryptography (asymmetric cryptography) is the foundation of the Internet and it is used for a variety of purposes.

Public and private keys can be stored in several different types of files. Each of these types can have its own encoding. The overall format of a file can be quite complex. It is important, however, to understand the purpose of these formats, and how they’re used.

This document can be used as a primer for understanding these file/encoding formats.

The actual structure (objects and fields) of public/private keys, including X.509 certificates, is specified in various RFCs using the ASN.1 notation.

For example, an RSA private key contains the following fields:

RSAPrivateKey ::= SEQUENCE {
  version           Version,
  modulus           INTEGER,  -- n
  publicExponent    INTEGER,  -- e
  privateExponent   INTEGER,  -- d
  prime1            INTEGER,  -- p
  prime2            INTEGER,  -- q
  exponent1         INTEGER,  -- d mod (p-1)
  exponent2         INTEGER,  -- d mod (q-1)
  coefficient       INTEGER,  -- (inverse of q) mod p
  otherPrimeInfos   OtherPrimeInfos OPTIONAL
}

The most widely used format is X.509 and it’s full syntax is defined by the RFC5280. X.509 provides the support for the “chain of trust” to verify a public key, as well as various extensions, primarily concerning the key’s usage. RFC5280 also documents formats for CSR, CLR, etc.

PKCS #8 specification defines the structure of private keys (PKCS stands for Public-Key Cryptography Standards).

These specifications only stipulate the structure (fields and objects), we still need to decide how to “encode” these fields when we want to save them on disk.

Security considerations aside, it would be nice if everything was stored in some sort of a structured format that we’re all used to, such as JSON or YAML, but this not the case for the majority of crypto formats, with the exception of JWK as explained later.

Read the rest of this post »

OAuth2 JWT Verification Best Practices

Posted on: October 15, 2019 | Posted in: Certificates, OAuth2, security

OAuth2 is very rapidly becoming the de-facto standard for securing APIs.
An OAuth2 JWT token is a signed JSON snippet containing fields (claims) that are needed to make a decision about granting access.

It is important to understand the inherent risks of OAuth2/JWT and make sure that the right mechanisms are in place to mitigate them.

A JWT token is similar to an X509 certificate. If a certificate is signed by a CA we trust (and if it is not expired, the signature is valid, etc.), we will trust the TLS client (or our browser will trust the server using this certificate). A JWT token is signed by an authorization server as opposed to a CA, so we have to trust the authorization server in order to authorize the client.

Read the rest of this post »

Self-Signed Certificates Best Practices and How-to Guide

Posted on: August 10, 2019 | Posted in: Certificates, security

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 Management Best Practices Summary

Posted on: November 25, 2018 | Posted in: Certificates, security

For more details, please refer to our certificate management document.

Best practices list:

* Restrict certificate validity to short periods of time
* Automate certificate renewal/refresh
* Implement certificate validation/revocation mechanism (OSCP)
* Do not use self-signed certs
* Do not use wildcard certs
* Establish and maintain a complete certificate inventory — you must know where each certificate is deployed, its expiration, etc.
* Run frequent endpoint/port scans to detect self-signed and other out-of-policy certificates.

Read the rest of this post »