Skip to main content

Certificate Signing Requests

When requesting a certificate from a Certificate Authority (CA) a special file called a Certificate Signing Request (CSR) is submitted. See also https://en.wikipedia.org/wiki/Certificate_signing_request

In the case of ACME domain validated certificates this CSR mainly just includes the list of domains you want to include on the certificate (other fields such as Organization etc are discarded because ACME doesn't validate these). The CSR is signed using your Private Key, verifiable using the public key included in the CSR. This ensures that the same entity who completed certificate validation is also the same entity submitting the certificate signing request.

Names in the CSR​

The CSR always includes the domains and IP addresses you requested, even if the CA leaves some of them out of its order (for example a wildcard). The CA will then either issue the certificate or reject the CSR, and the request log notes the difference.

Some CAs add names to the order that you did not request, most commonly the www variant of a domain. Certify still has to validate these names before the order is ready, and by default includes them in the CSR, so the certificate is issued with the names the CA has authorized. A warning in the request log lists the added names.

To leave added names out of the CSR, enable Strict ACME Order Identifiers in the instance settings (Settings > General in Certify Certificate Manager, or the Advanced tab of the instance settings in the Management Hub). A CA that checks the CSR against its order will then reject the request rather than issue a certificate with names you did not request.

OCSP Must-Staple​

In certificate request settings, enable Require OCSP Must-Staple to add the OCSP Must Staple extension to the CSR and resulting certificate.

CSR Signing Key Algorithm (Private Key)​

By default, Certify uses RSA 2048 for CSR signing keys (the certificate private key). This default was briefly changed in 6.x to ECDSA 256, but many older Windows Server versions were found to be incompatible with that default. You can set preferences globally or per managed certificate in product-specific certificate settings.

Re-use a Private Key​

In most cases you will want to use a new private key for each certificate request, but in some cases you may want to re-use an existing private key. For example, if you have a private key that is already in use by another system, or you have a private key that you want to use for multiple certificates. If you check Use the same Private Key for Renewals the app will generate a key on next renewal and re-use that for subsequent renewals of the same certificate.

You can also use a custom private key in PEM format from certificate signing/security settings.

Using a Custom CSR​

In most cases the CSR (and private key) is generated for you, but in some cases you may need to supply your own, so that the resulting certificate can be used with other systems which require a CSR based workflow (such as SAP, various servers and IoT devices including printers etc).

  1. Create or edit the target certificate request.
  2. In signing/security options, choose Custom CSR.
  3. Select your CSR file, then your private key file (required to build the final PFX).
  4. Request the certificate. Certify submits your CSR to the ACME CA, then downloads the signed certificate.

When you use a custom CSR as-is, the domains and key come from the CSR, so you can't edit the certificate's identifiers until you remove the CSR.

Using only the subject fields of a custom CSR​

Some CAs use subject fields from the CSR such as Organization (O), Organizational Unit (OU), Locality (L), State (ST) or Country (C). To supply these without fixing the domains and key in a CSR, enable Only use the subject fields from the custom CSR before choosing your CSR file.

Certify then copies the CSR's subject fields (but not its Common Name) into the CSR it generates for each request. That CSR uses the identifiers set for the certificate and its own private key, following your key type and key re-use settings. The domains and key in the custom CSR are ignored. The Include CN and OCSP Must-Staple options still apply.

If you enable the option after choosing your CSR, the certificate's identifiers stay as read from the CSR, and you can then edit them.

The Certificate Request step of the certificate's preview lists the subject fields that will be copied from your CSR. When a custom CSR is used as-is, it lists the CSR's subject fields and identifiers instead.