(DC) Platform FAQ

If you do not find the answer to your question here, please reach out to the Certificate Team, we will be happy to answer any questions.

Will the “no-challenge” challenge be supported in the CERTInext ACME implementation?
YES, so long as the ACME account is tied to the RSAOV type.

During the CERTInext transition: to what level, if not all, will account settings will be migrated from Sectigo to CERTInext - such as ACME accounts, the domains (FQDNs) assigned to them?
Certificate metadata is migrated. ACME accounts are migrated but need to be re-bound. Domains are assigned to groups and ACME accounts are assigned to groups. Departments are now groups in CERTInext.

Will any certificates be migrated from Sectigo to CERTInext?
Any certificates issued with Sectigo will continue to be validated by Sectigo and the certificate chain issued by Sectigo, until they expire. If you encounter any issues with your certificates, please reach out the Certificate Team.

Is there any ServiceNow integration?"

Yes, a very basic one. It is being enhanced.

Are there rate limits on the ACME endpoints, particularly newAccount and newOrder - per account, per EAB credential, or per source IP?

CERTInext currently does not impose rate limits on its ACME endpoints, including newAccount and newOrder. There are no rate limits per ACME account, EAB credential, or source IP address.

If CERTInext introduces rate limits in the future, they intend to publish those limits in advance.

One ACME protocol behavior that clients should account for is the use of replay nonces. A replay nonce can be used only once. When multiple ACME requests are being made in parallel, each client or request should obtain its own nonce rather than sharing a nonce between concurrent requests.

Can ACME accounts registered with CERTInext be viewed, listed, or deleted through the portal or an API?

No. CERTInext does not expose ACME accounts as manageable objects. There is currently no portal view or API that can be used to list or remove registered ACME accounts.

The administrative control available for managing access is the External Account Binding (EAB) credential. Revoking or deleting an EAB credential immediately prevents all ACME accounts registered with that credential from operating.

Because individual ACME accounts cannot be administratively removed, clients should generally persist and reuse their ACME account rather than continually creating new accounts.

What happens to existing ACME accounts if an EAB credential is revoked or deleted?

Revoking or deleting an EAB credential immediately disables every ACME account registered using that credential.

CERTInext checks the associated EAB credential on subsequent ACME requests, not only during initial account registration. Therefore, deleting or revoking an EAB credential effectively revokes all ACME accounts associated with it.

Existing accounts will no longer be able to perform operations such as certificate renewal. Requests made through those accounts will fail with an HTTP 401 Unauthorized response.

This behavior is important when rotating EAB credentials.

What is the recommended procedure for rotating an EAB credential?

The recommended sequence is:

1. Create the new EAB credential.

2. Configure each ACME client or tool to use the new credential.

3. Generate a new ACME account key for each tool.

4. Allow the client to register a new ACME account using the new EAB credential.

5. Confirm that the new account can successfully complete an actual certificate order.

6. Only after successful testing, revoke or delete the old EAB credential.

A new account key is important during this process. Reusing an existing account key may cause the ACME server to return the existing account, which remains associated with the old EAB credential.

Do not delete the old EAB credential until all clients using it have been successfully migrated and tested.

Do CERTInext ACME accounts expire after a period of inactivity?

No. Once registered, an ACME account does not expire or get automatically reclaimed because of inactivity.

An account’s state changes only through explicit account deactivation by the ACME client or through changes to the associated EAB credential, such as revocation or deletion.

Is domain validation associated with an individual ACME account or with the organization?
Domain validation state is maintained at the organization level rather than being tied to an individual ACME account.

As a result, a newly registered ACME account can benefit from domains that have already been verified for the organization and does not need to repeat domain validation simply because a new ACME account was created.

An ACME authorization object will still be created for each identifier in an order, as required by RFC 8555. When an existing organizational validation applies, however, the authorization can be returned in an already-valid state.

Should an ACME client persist its account key and reuse the same account?

Yes. The recommended practice is to persist one ACME account key per tool and reuse that ACME account indefinitely.

Clients should not normally generate a new account key and register a new ACME account every time they run.

If different certificate configurations require different EAB credentials or certificate products, a tool may need separate credentials and corresponding ACME accounts for those configurations.

Do ACME clients cache account and EAB information locally?

Yes. Many ACME clients persist information about the registered account, including the account key, account URL, and EAB-related configuration.

Examples include:

• certbot: account information under /etc/letsencrypt/accounts

• cert-manager: account information in the Issuer/ClusterIssuer Secret and associated status

• acme.sh: account information under ~/.acme.sh

• lego: account information under .lego/accounts

When changing an EAB credential or ACME account key, the client’s cached account state may also need to be cleared or updated so that the client performs a new account registration.

If stale account information remains cached, a client may continue presenting its previous account URL and receive an HTTP 401 Unauthorized response even though the newly configured EAB credential itself is valid.

For this reason, credential rotation should always be verified by completing an actual certificate order. A successful account registration alone should not be considered sufficient validation of the new configuration.