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.
Read the rest of this post »

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

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

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

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 unsecure, 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 »

How to Troubleshoot and Fix Certificate Validation Issues in Java

July 25, 2019 | Posted in certificates,security

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 »

Java Keystore Management Best Practices

July 23, 2019 | Posted in certificates,security

A keystore file is a database for storing application secrets (private keys), trust certificates and CA chains. Proper keystore/truststore management is extremely important for application security.

We’ve compiled a list of keystore-related best practices in our keystore management document.

Here is a brief summary of the document:
Read the rest of this post »

Certificate Management Best Practices Summary

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 »

Certificate Management Best Practices Document

November 8, 2018 | Posted in certificates,security

We're incorporating more security reporting/compliance features into DPBuddy and we're also working on a new product related to certificate management.

As part of this work, we're attempting to compile and aggregate best practices related to certificates and key management.
Read the rest of this post »

DataPower Buddy Release 3.4

May 30, 2018 | Posted in Ant,DataPower,dpbuddy,gradle

We're pleased to announce the availability of DataPower Buddy 3.4.

This release provides support for DataPower firmware upgrades, extensive configuration reporting and diffing, DataPower operational analytics and many other features.

Please see release notes for more information.

Download PBuddy 3.4 from this page and follow our Quick Start Guide.

DataPower Buddy Roadmap

May 29, 2018 | Posted in DataPower,dpbuddy

Next DPBuddy release will provide improved operational analytics and certificate management. We're also working on improved configuration reports and configuration diff.

We're also planning on implementing native plugins for Maven and Gradle.

What else would you like to see in the upcoming versions of the product? Please let us know.

Running DPBuddy from Docker

May 5, 2018 | Posted in DataPower,dpbuddy

You can now use our DPBuddy docker image that comes pre-installed with Java, Apache Ant and DPBuddy.
Simply run "docker pull myarch/dpbuddy:3.4" and follow our documentation.

DPBuddy Cookbook

October 9, 2017 | Posted in DataPower,dpbuddy

Our cookbook contains quick examples/samples/code snippets to help with the most common DataPower development and administration tasks. The cookbook is a live document and it is frequently updated with new information.

Collecting and Analyzing DataPower Logs with DPBuddy and Elastic Stack

August 30, 2017 | Posted in DataPower,dpbuddy

Please follow this link.

Automating DataPower Firmware Upgrades with DPBuddy

January 29, 2017 | Posted in DataPower,dpbuddy

How to Deal with Generated DataPower Policies

July 25, 2016 | Posted in DataPower,dpbuddy