Revocation & CRL/OCSP

Revoking a certificate in Sectigo Edge is immediate and permanent. Sectigo Edge then publishes the new status to relying parties, through a certificate revocation list (CRL) and through pre-produced OCSP responses. Revocation and publication are tracked separately: if publication is briefly unavailable, the certificate stays revoked and publication is retried until it succeeds.

Revoke a certificate

Sectigo Edge console

Revocation is a one-party safety action. It cannot be undone.

1. Open Console›Certificates, find the certificate set, and select Revoke.
2. Choose the RFC 5280 reason: Key compromise, Superseded, Cessation of operation, Affiliation changed, Privilege withdrawn, Certificate hold or Unspecified.
3. If the set has a healthy standby, leave Promote healthy standby first selected. The service then keeps running on the standby while the compromised certificate is removed.
4. In Audited incident context, enter the ticket, evidence or other context. It becomes part of the audit record.
5. Select Revoke now.

You need revocation permission and fresh MFA. One person is enough: revocation removes trust, so it does not need a second approver. New issuance still needs both trust domains.

warning

Revocation cannot be undone, and Certificate hold is no exception: you cannot release a held certificate from the console. If you need the service back, issue a new certificate.

tip

Revocation still works while the issuance kill switch is active. Pausing issuance during an incident does not stop you from revoking.

What relying parties see

CRL

Certificates issued through the built-in path carry a CRL distribution point of this form:

https://sharppki.com/pki/<tenant-id>/crl/<connector-id>.crl

• It answers GET and HEAD without a sign-in, because clients must be able to check status before they trust a certificate.
• It always serves the latest committed CRL, with content type application/pkix-crl.
• Responses may be cached for at most one hour.
• When fewer than five minutes remain before the CRL's nextUpdate, or storage is unavailable, the endpoint returns 503. It never serves a stale CRL.

OCSP

The OCSP responder lives at:

https://sharppki.com/pki/<tenant-id>/ocsp/<connector-id>

• It accepts OCSP POST and RFC 5019-style GET requests.
• Responses are pre-produced for both SHA-1 and SHA-256 CertIDs, so older and newer clients both work.
• Cache headers come from the signed nextUpdate. A response with less than five minutes left is never served.

Errors are returned as OCSP responses, not product JSON:

OCSP status	When
malformedRequest	The request is malformed or unsupported.
tryLater	The certificate is recognized, but no fresh, verified response is published yet.
unauthorized	The certificate or issuer is unknown to this responder.

The responder serves a cache profile. Requests that are signed, that carry more than one CertID, or that include extensions or a nonce are rejected. Configure clients not to send OCSP nonces to this responder.

Publication cadence

Event	CRL	OCSP
First successful issuance for an authority	CRL generation 1 is created, even if empty, so certificates never point at an uninitialized endpoint.	good responses are pre-produced for both hashes.
A certificate is revoked	A new CRL generation is requested immediately.	New revoked responses are published immediately.
Publication fails	The certificate stays revoked. Its publication status is pending. Retries start after 1 minute, then every 5 minutes.	Same: the revoked state is kept, and publication is retried durably.
Routine refresh	—	Each accepted response is refreshed one hour before its nextUpdate.

Each CRL publication is checked independently before it goes live: signature, issuer, cRLSign key usage, freshness, every required serial, reason and time, and a strictly increasing CRL number. A refresh can never overwrite or renumber an earlier generation.

Monitor and refresh

Sectigo Edge console

Revocation shows OCSP health per certificate and CertID hash, and CRL generation and next update per CA.

Console›Revocation shows:

• healthy OCSP responses, responses needing attention (pending or refresh due) and current revocation lists
• for each OCSP response: signing authority, serial, generation, CertID hash, status and next update
• for each CA: CRL number, number of revoked entries, generation, next update and status

Status	Meaning
healthy	A verified, current artifact is published.
pending	Publication is waiting or being retried.
refresh due (OCSP)	The response is near its refresh point.
expired (CRL)	The latest CRL has expired. The public endpoint returns 503.
external	Microsoft ADCS: the local CA has not yet produced an accepted artifact for the latest change. See below.

To force a new publication:

Action	Where	Confirmation
Publish new CRL	The CA's card under Certificate revocation lists	Type REFRESH CRL
Refresh OCSP (or Queue, for ADCS)	The response's row in OCSP response service	Type REFRESH OCSP

Both need revocation permission and fresh MFA, which are checked again on submit.

Sectigo Edge console

Publishing a CRL. The signer must return a fresh CA-signed CRL that contains every known revocation.

Microsoft ADCS

With Microsoft ADCS, your local CA stays the authority. A healthy Windows Mesh Node assigned to the ADCS integration publishes and retrieves the CA-signed CRL and gets OCSP responses from your configured Microsoft Online Responder. Sectigo Edge verifies these artifacts before it serves them. It never fabricates an ADCS CRL or OCSP response.

• The status shows external until the node uploads an accepted artifact. It then becomes healthy.
• Publish new CRL is disabled for ADCS authorities. The button shows Local CA managed.
• Publication requests survive node, CA and network outages and are redelivered.
• A successful ADCS CRL does not mean OCSP is working. They are tracked independently.

See Microsoft ADCS.

Verify revocation from a client

workstation (bash)

$ curl -sI https://sharppki.com/pki/acme-corp/crl/ca_prod_issuing.crl
HTTP/2 200
content-type: application/pkix-crl
$ curl -s -o latest.crl https://sharppki.com/pki/acme-corp/crl/ca_prod_issuing.crl
$ openssl crl -inform DER -in latest.crl -noout -nextupdate -crlnumber
nextUpdate=Oct  2 14:00:00 2026 GMT
crlNumber=0x2A
$ openssl ocsp -issuer issuing-ca.pem -cert service.pem -no_nonce \
>   -url https://sharppki.com/pki/acme-corp/ocsp/ca_prod_issuing
service.pem: revoked
  This Update: Oct  1 14:00:00 2026 GMT
  Next Update: Oct  2 14:00:00 2026 GMT
  Reason: keyCompromise
  Revocation Time: Oct  1 13:58:41 2026 GMT

Use -no_nonce. A request with a nonce is rejected by the cache profile.

Errors you may see

Code	Meaning	What to do
certificate_not_revocable	Only an issued certificate can be revoked. It may already be revoked.	Refresh the certificate list.
invalid_revocation_reason	The reason is not recognized.	Choose one of the listed reasons.
revocation_comment_too_long	The incident context is too long.	Shorten it, and link to your ticket instead.
crl_context_required	The CA has not completed an issuance yet, so there is no CRL to publish.	Issue one certificate first.
crl_expired (503 at the public URL)	The latest CRL is expired or too close to expiry.	Select Publish new CRL. If it keeps failing, check the CA connection.
crl_partition_required	The CA has more than 50,000 active revocations.	A partitioned CRL configuration is needed. Raise it with your Sectigo Edge platform contact before the CA reaches this limit.
remote_crl_publication_failed / remote_ocsp_publication_failed	The protected signing service rejected the publication.	Retry. If it persists, check the CA connector under Console›CAs & signing.
crl_publication_raced / ocsp_publication_raced	Another publication changed the generation at the same moment.	Retry. Generations are never overwritten.

Related

• Revocation console reference
• Zero-downtime rotation
• Incident response & break-glass