Archive for May, 2020

Automating Crypto Deployment with DPBuddy

Posted on 05/24/2020 , Alexander,

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.

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.

Mandatory Certificate Extensions

Posted on 05/14/2020 , Alexander,

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 05/13/2020 , Alexander,

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.