Category Archives: Certificates

Comprehensive Certificate, Key and Password Inventory with DPBuddy

Posted on: June 21, 2020 | Posted in: Certificates, DataPower, DPBuddy

DPBuddy 3.5 supports in-depth inventory and analysis of your X.509 certificates and keys:

  • Inventory of all your certificates, keys and password aliases across all of your appliances and domains.
    In addition to DataPower, the inventory includes certificates from TLS endpoints.
  • Reports in Excel and text format
  • Certificate deduplication — find all places where a given certificate is used
  • See audit records of all changes — who changed what when
  • See how each of your crypto objects is used by other DataPower objects
  • See expiration for passwords/password aliases (in addition to certificates’ expiration)
  • Ensure compliance and best practices: identify self-signed certificates, weak keys/algorithms, unapproved signers
  • Get alerted on certificate expiration, invalid signatures, revocation, policy violations


Read the rest of this post »

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 »

Automating Crypto Deployment with DPBuddy

Posted on: May 24, 2020 | Posted in: Certificates, DataPower, DPBuddy

DPBuddy 3.5 supports fully automated deployment of X.509 certificates and keys with the following capabilities:

  • Deployment from standalone files in various formats (PEM, DER, PKCS8, etc.), encrypted and unencrypted.
  • Deployment from Java keystores/truststores in various formats (JKS, PKSC12, etc.). You can specify a list of aliases to deploy a subset of certs/keys from a keystore.
  • Deployment directly from TLS endpoints to DataPower.
  • Automatic deployment of issuers/CA certs. DPBuddy can also download the issuer from the certificate’s AIA extension if exists (all certs issued by known CAs will have that extension).
  • Auditing of all changes to crypto objects directly on DataPower. You can see who changed what when using DPBuddy’s crypto reporting task.
  • Keystores and key passwords can be stored encrypted in DPBuddy’s conf file or provided directly on the command line.
  • Deployment is automatically validated to make sure all crypto objects and password aliases are up.
  • Crypto Identity Credential objects are created automatically for cert-key keypairs from a keystore.

We’ve also developed a framework for integrating with your Key Management System of choice, such as Hashicorp Vault or AWS Key Management Service.

DPBuddy copies keys/cert files to DataPower (as PEM files) and creates DataPower crypto objects. The names derived either from filenames or from the names (aliases) in the keystore.

DPBuddy automatically determines if the source is a key or a cert and creates the crypto objects of the appropriate type.

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 »