--- title: "ETSI EN 319 411-1 Revocation, OCSP, and CRL Operations" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/revocation-ocsp-and-crl-operations" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/revocation-ocsp-and-crl-operations" author: "Sorena AI" description: "Operate ETSI EN 319 411-1 revocation status services with CPS procedures, authenticated requests, 24-hour CRL or OCSP publication controls, and audit evidence." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "ETSI EN 319 411-1 revocation" - "OCSP operations" - "CRL publication" - "certificate status services" - "CPS" - "ETSI EN 319 411-1" - "revocation status services" - "OCSP" - "CRL" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 411-1 Revocation, OCSP, and CRL Operations Operate ETSI EN 319 411-1 revocation status services with CPS procedures, authenticated requests, 24-hour CRL or OCSP publication controls, and audit evidence. *Artifact Guide* *GLOBAL* *ETSI EN 319 411-1* ## ETSI EN 319 411-1 Revocation, OCSP, and CRL Operations A focused operating guide for CA revocation request intake, status-service publication, CRL cadence, OCSP support, and consistency evidence under ETSI EN 319 411-1. Grounded in ETSI EN 319 411-1 clauses 6.2.4, 6.3.9, 6.3.10, and 6.6, with EN 319 401 evidence-record support. Use this page to structure the operational controls behind certificate revocation and status services. EN 319 411-1 expects the CPS to define who can request revocation, how requests are confirmed and authenticated, how quickly status changes reach relying parties, whether OCSP or CRL is supported, and how multiple status methods remain consistent over time. ## Define the CPS operating rules before accepting revocation traffic Start with the CPS because EN 319 411-1 makes revocation operations a published practice, not only a back-office ticket queue. The CPS needs to state who can submit revocation requests or event reports, how those requests are submitted, what confirmation is required, whether certificates can be suspended or revoked, which mechanism distributes status information, and the maximum delays before relying parties can see the status change. The operating design should separate revocation management from revocation status distribution. Revocation management decides the action to take on a request or event report; the status service exposes the resulting certificate status to relying parties through OCSP, CRL, or both. - List authorized request sources in the CPS, including subscriber, subject, RA, CA operations role, incident channel, or other approved reporter categories. - Document request intake channels, required confirmation steps, authentication checks, authorization checks, and the procedure for requests that cannot be confirmed within 24 hours. - Define the maximum delay from request receipt to status availability for relying parties, and apply the 24-hour maximum where EN 319 411-1 requires it. - Synchronize the time used for revocation services with UTC at least once every 24 hours so request receipt, decision, and publication evidence can be compared. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Clauses 6.2.4 and 4.3 ground the CPS procedure fields, revocation management role, revocation status service role, 24-hour status timing, request authentication, and UTC synchronization requirements. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Clause 7.10 supports precise event-time records, UTC synchronization for audit-log time, and protected operational records. ## Operate revocation decisions as traceable status changes EN 319 411-1 requires timely revocation based on authorized and validated requests, and it also names events that require revocation of non-expired certificates. The operational file should therefore prove the full path: request or event report received, authenticated, checked against the authorized source, decided by the responsible trusted role, and converted into updated status information. If suspension is available, keep it distinct from definitive revocation. A definitively revoked certificate is not reinstated, while a suspended certificate needs its own status-change and notification handling. Where possible, the subject and subscriber should be informed when a certificate is revoked or suspended. - Record the certificate identifier, certificate profile or policy, subject or subscriber reference, request source, intake timestamp, authentication method, authorization basis, decision, reason, and status-change timestamp. - When confirmation cannot be completed within 24 hours, retain the exception procedure, actions taken, and case justification required by the CPS. - For future-dated revocation requests, document the scheduled date used as the operative receipt time and keep the original request attached. - Keep revocation request logs and resulting actions with the certificate lifecycle audit records, not only in a service desk system. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Clauses 6.3.9 and 6.4.5 ground timely revocation, non-reinstatement after definitive revocation, notice where possible, and logging of revocation requests and resulting actions. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Clause 7.10 supports retaining service-operation records as accessible evidence for continuity and legal proceedings. ## Run CRL publication with cadence, signing, and nextUpdate evidence Where CRLs are used for end-user certificates, EN 319 411-1 gives concrete operating checks. A CRL or variant, such as a delta CRL, is published at least every 24 hours until the last CRL has been published. Each CRL states the time of the next scheduled CRL issue unless it is the last CRL for that certificate scope, and the CRL is signed by the CA or an entity designated by the TSP. A useful CRL evidence file shows the published CRL, publication timestamp, nextUpdate value, signing authority, certificate scope, and any delta or last-CRL handling. It should also show how relying parties find the CRL and how the CA confirms that changed revocation status reached the CRL path within the CPS timing commitment. - Keep CRL files or hashes, publication logs, distribution point evidence, next scheduled issue times, signing-certificate evidence, and monitoring results for each certificate scope. - If a last CRL is issued for a scope, preserve the reason, scope boundary, final CRL evidence, and nextUpdate treatment. - If CARLs are used for CA certificates, track the yearly generation rule, the trigger for a new CARL after CA certificate revocation, and cross-certificate handling where applicable. - Do not treat a daily CRL job as sufficient evidence unless the file proves the CRL was published, signed correctly, and available to relying parties. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Clauses 6.3.9 and 6.6.2 ground the 24-hour CRL publication cadence, nextUpdate handling, CA or designated-entity signing, CARL triggers, and RFC 5280 CRL profile expectation. *Recommended next step* *Placement: after operational checklist* ## Prepare OCSP and CRL evidence Use this ETSI EN 319 411-1 guide to align CPS commitments, revocation request handling, CRL publication proof, OCSP responder records, and status-service consistency evidence. - [Open Assessment Autopilot for ETSI EN 319 411-1](/solutions/assessment.md): Convert revocation, OCSP, and CRL controls into assigned evidence requests and review-ready records. - [Research ETSI EN 319 411-1 source questions](/solutions/research-copilot.md): Resolve clause, CPS, timing, CRL, OCSP, and status-service consistency questions against cited ETSI sources. - [Talk through revocation status operations](/contact.md): Review missing CPS fields, publication evidence, OCSP responder proof, and CRL consistency gaps before audit handoff. ## Operate OCSP and multi-method status services consistently EN 319 411-1 requires services for checking certificate status and says OCSP or CRL shall be supported, with OCSP recommended. Revocation status information must be available 24 hours per day, seven days per week, protected for integrity and authenticity, include status information at least until the certificate expires, and be publicly and internationally available. When both CRL and OCSP are used, status updates need to become available through all supported methods. The services also need to remain consistent over time, while allowing documented differences in update delays. If those delays exist or are possible, the CPS should explain their origin and how relying parties should interpret temporary differences. - For OCSP, keep responder configuration, sample responses, signer certificate evidence, RFC 6960 profile evidence, monitoring logs, and evidence that non-issued certificate requests are not answered with a good status. - For CRL and OCSP together, keep a consistency record showing the request decision, OCSP update time, CRL update time, allowed delay source, CPS explanation, and final same-status outcome. - Protect status information integrity and authenticity, and enforce access control on attempts to modify revocation status information. - Measure outage handling against the CPS maximum unavailability commitment instead of relying on a generic uptime statement. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Clauses 6.3.10, 6.5.4, and 6.6.3 ground status-service availability, integrity, OCSP-or-CRL support, multi-method consistency, public availability, status modification access control, and RFC 6960 OCSP profile requirements. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Clause 7.10 supports preserving integrity-protected records that prove correct operation of the status services. ## Evidence checklist for revocation, OCSP, and CRL operations Use this checklist before an audit handoff or customer evidence request. It is scoped to operational proof for revocation and status services; it does not supersede the full EN 319 411-1 conformity assessment or any external scheme requirement. - CPS coverage: authorized request sources, submission channels, confirmation rules, suspension and revocation reasons, status distribution method, and maximum publication delays are stated. - Request evidence: each revocation request or event report has intake time, authentication, authorization, decision, reason, and resulting action records. - Timing evidence: revocation-service time is synchronized with UTC, and request-to-status-availability measurements show the applicable 24-hour rule was met or an exception was recorded. - CRL evidence: publication cadence, nextUpdate values, signed CRL files or hashes, CRL variants, CARL handling, and last-CRL treatment are retained where used. - OCSP evidence: responder profile, signer evidence, sample responses, non-issued certificate behavior, monitoring logs, and access-control evidence are retained where used. - Consistency evidence: when CRL and OCSP are both supported, differences in update timing are documented in the CPS and final status consistency is checked. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the checklist items covering CPS revocation procedures, revocation request logs, CRL operation, OCSP operation, status-service consistency, and audit logging. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports preserving accessible, confidential, integrity-protected operational records for evidence and service continuity. ## Primary sources - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Primary source for the page's revocation request, suspension, CRL publication, OCSP, certificate status service, profile, timing, and audit-log claims. - Quote: "Certificate status services" - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Primary source for the page's event-time, UTC synchronization, archive confidentiality, integrity, accessibility, and service-operation evidence claims. - Quote: "Collection of evidence" ## Related Topic Guides - [CP vs CPS under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/cp-vs-cps.md): Understand how ETSI EN 319 411-1 separates Certificate Policy from Certification Practice Statement work for certification authorities and trust service providers. - [EN 319 411-1 vs EN 319 411-2 Certificate Policy](/artifacts/global/etsi-en-319-411-1/en-319-411-1-vs-en-319-411-2.md): Compare ETSI EN 319 411-1 general certificate-service requirements with EN 319 411-2 EU qualified certificate requirements, including policy scope, CP/CPS evidence, and audit boundaries. - [ETSI EN 319 411-1 Audit File Evidence](/artifacts/global/etsi-en-319-411-1/audit-file-evidence.md): Build an ETSI EN 319 411-1 audit evidence file for CA logging, registration records, revocation records, CA key lifecycle evidence, and records archival. - [ETSI EN 319 411-1 CA Key Management](/artifacts/global/etsi-en-319-411-1/ca-key-management.md): CA key management guidance for ETSI EN 319 411-1: CPS commitments, key ceremonies, secure cryptographic devices, backup, recovery, and lifecycle evidence. - [ETSI EN 319 411-1 certificate lifecycle workflow](/artifacts/global/etsi-en-319-411-1/certificate-lifecycle-workflow.md): Workflow for EN 319 411-1 certificate application, issuance, acceptance, renewal, re-key, modification, revocation, suspension, status services, and evidence records. - [ETSI EN 319 411-1 certificate re-key FAQ](/artifacts/global/etsi-en-319-411-1/faq/re-key.md): What ETSI EN 319 411-1 requires when a TSP re-keys an existing certificate with a new subject public key. - [ETSI EN 319 411-1 Certificate Suspension FAQ](/artifacts/global/etsi-en-319-411-1/faq/suspension.md): How CAs should handle certificate suspension under ETSI EN 319 411-1: CPS disclosure, validated requests, status publication, subscriber notice, and audit evidence. - [ETSI EN 319 411-1 Certification Audit Evidence FAQ](/artifacts/global/etsi-en-319-411-1/faq/certification-audit-evidence.md): How CAs should prepare ETSI EN 319 411-1 audit evidence for CP/CPS scope, registration records, revocation records, CA key logs, and retained assessment files. - [ETSI EN 319 411-1 Compliance Guide](/artifacts/global/etsi-en-319-411-1/compliance.md): Build an ETSI EN 319 411-1 compliance file for certificate policies, CPS commitments, certificate lifecycle controls, revocation services, CA keys, and audit evidence. - [ETSI EN 319 411-1 CP and CPS template](/artifacts/global/etsi-en-319-411-1/cp-and-cps-template.md): Build a certificate policy and Certification Practice Statement template for ETSI EN 319 411-1 certificate services, with fields for policy identifiers, subscribers, relying parties, revocation, publication, and evidence. - [ETSI EN 319 411-1 FAQ for Certificate Services](/artifacts/global/etsi-en-319-411-1/faq.md): Answers to common ETSI EN 319 411-1 questions on certificate policies, CPS content, CA and RA boundaries, subscriber evidence, revocation, status services, and record retention. - [ETSI EN 319 411-1 Identity Validation](/artifacts/global/etsi-en-319-411-1/identity-validation.md): Identity validation requirements in ETSI EN 319 411-1 for subscribers, subjects, RAs, certificate requests, registration evidence, and issuance records. - [ETSI EN 319 411-1 Identity Validation Evidence Workflow](/artifacts/global/etsi-en-319-411-1/identity-validation-evidence-workflow.md): A workflow for building ETSI EN 319 411-1 identity validation evidence packs across subscriber, subject, certificate request, RA, logging, and retention controls. - [ETSI EN 319 411-1 RA Delegation Guide](/artifacts/global/etsi-en-319-411-1/ra-delegation.md): How to scope registration authority delegation under ETSI EN 319 411-1, including delegated RA tasks, external provider controls, registration records, and audit evidence. - [ETSI EN 319 411-1 RA Delegation Review Workflow](/artifacts/global/etsi-en-319-411-1/ra-delegation-review-workflow.md): Review delegated registration authority work under ETSI EN 319 411-1: retained CA responsibility, recognized registration service providers, secure data exchange, CPS coverage, and audit evidence. - [ETSI EN 319 411-1 requirements map for certificate services](/artifacts/global/etsi-en-319-411-1/requirements.md): Map ETSI EN 319 411-1 requirements for certificate policies, CP/CPS content, registration, revocation, certificate status, and CA key-management evidence. - [ETSI EN 319 411-1 Revocation Evidence Workflow](/artifacts/global/etsi-en-319-411-1/revocation-evidence-workflow.md): Build a revocation evidence workflow for ETSI EN 319 411-1 covering CPS procedures, request authentication, 24-hour status updates, CRL/OCSP publication, logs, and retention. - [ETSI EN 319 411-1 vs CA/B Forum Baseline Requirements](/artifacts/global/etsi-en-319-411-1/en-319-411-1-vs-ca-browser-forum-baseline-requirements.md): Compare how EN 319 411-1 incorporates CA/B Forum BRG concepts for DVCP, OVCP, IVCP, [WEB] requirements, CPS disclosure, domain validation, and conflict handling. - [How should certificate authorities handle revocation evidence under ETSI EN 319 411-1?](/artifacts/global/etsi-en-319-411-1/faq/revocation-evidence.md): What ETSI EN 319 411-1 expects CAs to evidence for certificate revocation requests, status publication, CRL or OCSP updates, and archived revocation records. - [RA delegation under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/ra-delegation.md): How certificate authorities can delegate registration authority work under ETSI EN 319 411-1 while keeping identity validation, secure data exchange, role controls, and audit evidence traceable. - [Subscriber agreements under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/subscriber-agreements.md): How ETSI EN 319 411-1 expects CAs and TSPs to inform subscribers, record acceptance, handle subject consent, and retain subscriber-agreement evidence. - [Subscriber identity validation under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/subscriber-identity-validation.md): How certificate authorities should validate subscriber and subject identity under ETSI EN 319 411-1, including evidence, authorization, subject categories, and registration records. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-411-1/revocation-ocsp-and-crl-operations