This section describes known issues and limitations for Entrust Certificate Enrollment Gateway. For other known issues with Certificate Enrollment Gateway, see the Knowledge section of Entrust TrustedCare. Reference numbers are for internal purposes only.

Configuration backup is only supported in single-node deployments (CSF-704)

Certificate Enrollment Gateway is deployed as a solution into Entrust Deployment Manager. Only single-node deployments of Entrust Deployment Manager support the clusterctl backup config command for exporting the cluster configuration. For information about the limitations and workaround for a multi-node backup and restore process, see the Entrust Deployment Manager documentation.

Unsupported ACMEv2 features (PKI-30901)

The Certificate Enrollment Gateway implementation of the ACME Server does not support the following RFC 8555 features:

• EdDSA signature algorithm
• Rate limits
• termsOfService optional string
• Changes of Terms of Service
• External Account Binding
• Pre-authorization

Unsupported Intune-SCEP operations (PKI-28149, PKI-31351)

The Certificate Enrollment Gateway integration with the Intune-SCEP protocol does not support the following draft-nourse-scep-23 operations:

• GetCRL
• GetNextCACert

CSRs sent from ACMEv2 clients cannot have an empty Subject DN if they will be sent to Entrust Certificate Services for processing (ECSPR-39482)

If an ACMEv2 client sends a CSR (certificate signing request) with an empty Subject DN, Certificate Enrollment Gateway will use the first Subject Alternative Name value in the CSR as the Subject DN. Certificate Enrollment Gateway will not alter the CSR, but will send the Subject DN value as a separate parameter to CA Gateway for processing. Entrust Certificate Services requires that CSRs must have a Subject DN. Entrust Certificate Services will ignore the Subject DN parameter sent by Certificate Enrollment Gateway.

Workaround: You must generate the CSR externally from the ACMEv2 client using another tool, such as openssl. The ACMEv2 client can then use the externally-generated CSR.

CSRs sent from ACMEv2 clients cannot have an empty Subject DN if they will be sent to a Microsoft CA for processing (PKI-32853)

If an ACMEv2 client sends a CSR (certificate signing request) with an empty Subject DN, Certificate Enrollment Gateway will use the first Subject Alternative Name value in the CSR as the Subject DN. Certificate Enrollment Gateway will not alter the CSR, but will send the Subject DN value as a separate parameter to CA Gateway for processing. A Microsoft Certification Authority (CA) requires that CSRs must have a Subject DN. A Microsoft CA will ignore the Subject DN parameter sent by Certificate Enrollment Gateway.

Note: This issue does not occur when using Certificate Enrollment Gateway with CA Gateway 2.5.0 or later. When using CA Gateway 2.5.0 or later, ACMEv2 clients can send a CSR with an empty Subject DN intended for a Microsoft CA without issue.

Workaround: You must generate the CSR externally from the ACMEv2 client using another tool, such as OpenSSL. The ACMEv2 client can then use the externally-generated CSR.

Authentication error message is always logged when enrolling for a certificate with a Cisco LibEST client using basic authentication (CEG-3287)

When enrolling for a certificate with a Cisco LibEST client and the client is using basic authentication, Certificate Enrollment Gateway will always log an authentication error, even when the simpleenroll and serverkeygen operations are successful. For example:

This error is expected with the LibEST client. Even when using basic authentication, the LibEST client does not provide the parameters for basic authentication on the first request. When the EST server does not obtain the basic authentication parameters on the first request, it issues header "WWW-Authenticate" to the LibEST client. When LibEST client receives the "WWW-Authenticate" header, the client will repeat the request and include the basic authentication parameters.