--- title: "ETSI EN 319 411-1 certificate re-key FAQ" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/faq/re-key" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/faq/re-key" author: "Sorena AI" description: "What ETSI EN 319 411-1 requires when a TSP re-keys an existing certificate with a new subject public key." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "ETSI EN 319 411-1" - "certificate re-key" - "trust service provider" - "CP/CPS" - "certificate lifecycle" --- **[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 certificate re-key FAQ What ETSI EN 319 411-1 requires when a TSP re-keys an existing certificate with a new subject public key. *FAQ* *GLOBAL* *ETSI EN 319 411-1* ## ETSI EN 319 411-1 Certificate re-key FAQ A focused answer for TSP, CA, RA, and audit teams handling certificate re-key under ETSI EN 319 411-1. Grounded in ETSI EN 319 411-1 V1.5.1 and the related ETSI EN 319 401 general TSP requirements. Under ETSI EN 319 411-1, certificate re-key is not the same as renewal. Re-key means issuing a new certificate for an already issued subject with a new subject public key; the certificate may also update subject attributes or the expiry date when the CP/CPS allows it. ## How should certificate authorities handle re-key under ETSI EN 319 411-1? Treat re-key as a certificate lifecycle event that starts with a new subject public key. ETSI EN 319 411-1 clause 6.3.7 says the general certificate application and application-processing requirements in clauses 6.3.1 and 6.3.2 still apply, so the request must remain linked to registration, authorization, identity or attribute evidence, and the public key being certified. The CP/CPS should be the operating boundary. It needs to state whether, and under which circumstances, the TSP allows certificate re-key to change the expiry date or certified attributes. If the previous certificate is used to authenticate the re-key request, the TSP checks that the previous certificate exists and is valid. - Confirm the event is re-key, not renewal: the subject public key changes. - Apply the certificate application and processing controls from clauses 6.3.1 and 6.3.2 to the re-key request. - Verify and record changed certified names or attributes before including them in the replacement certificate. - Check the existing certificate when it is used to authenticate the request. - Communicate and obtain agreement to changed terms and conditions before completing the re-key. 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) - Defines certificate re-key as issuance with a new subject public key and lists the clause 6.3.7 controls for attributes, expiry changes, previous-certificate authentication, and changed terms. - [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) - Provides the general trust service provider policy framework referenced by ETSI EN 319 411-1 for governance, practice statements, security, and auditability. ## What evidence should support certificate re-key? The evidence should prove why the re-key was allowed and how the new certificate was bound to the right subject. At minimum, keep the re-key request, request authentication result, registration or attribute evidence reused or refreshed, subscriber authorization where the subscriber and subject differ, and the CP/CPS rule that permits any expiry-date or attribute change. ETSI EN 319 411-1 also makes logging specific: registration events include requests for certificate re-key or renewal. Records archival then requires retention of relevant lifecycle logs and certificate documentation for at least seven years after any certificate based on those records ceases to be valid. - Request record showing the subject, subscriber, requested public key, certificate profile, and reason for re-key. - Proof of possession or control for a non-CA-generated subject private key where clause 6.3.1 requires it. - Validation record for any changed certified name, organization, device, system, or other subject attribute. - Evidence that changed TSP terms and conditions were communicated and agreed to when applicable. - Audit logs for registration, certificate generation, certificate dissemination, and any related revocation decision. 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 evidence list through clause 6.3.7 re-key requirements, clause 6.3.1 application requirements, clause 6.4.5 logging requirements, and clause 6.4.6 archival retention. - [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 the need for TSP-wide governance and audit controls behind the ETSI EN 319 411-1 certificate lifecycle evidence. ## When should re-key trigger revocation, notification, or CA key-change work? A subject-certificate re-key can happen before expiry, after expiry, or after revocation. When the re-key is driven by compromise or a security breach, handle the revocation path separately from the replacement-certificate path: revocation requests and reports must be authenticated, processed on receipt, and reflected in status information within the maximum delay required by the CPS and ETSI EN 319 411-1. Do not confuse subject-certificate re-key with CA key changeover. For CA certificate-signing keys, ETSI EN 319 411-1 has separate requirements to generate and distribute a new CA certificate before expiry when the service continues, allow affected parties enough interval to prepare, and document the CA key-pair generation procedure and ceremony evidence. - If the old certificate was revoked for key compromise, keep the revocation request, authentication, decision, status-publication evidence, and subscriber or subject notification record. - If cryptography or associated parameters become insufficient for remaining use, inform subscribers and relying parties with whom the TSP has relationships and make the information available to other relying parties. - For CA key changeover, keep the documented ceremony procedure, participating roles, responsibilities, collected evidence, and ceremony report. - For subject keys generated by the CA, preserve evidence that delivery protected secrecy and integrity and that copies were deleted after delivery except where escrow or recovery rules apply. 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 distinction between certificate re-key, revocation and suspension handling, algorithm-compromise notification, subject-key delivery, and CA key changeover ceremony 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) - Supports the broader TSP continuity, security, and operational-control context for revocation, compromise response, and CA key-change governance. ## 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 certificate re-key definition and requirements in clause 6.3.7, related certificate application controls, logging, archival, revocation, and CA key-changeover requirements. - Quote: "Certificate re-key refers to the issuance of a new certificate with a new subject public key." - [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) - Referenced by ETSI EN 319 411-1 as the general policy-requirements standard for trust service providers. - Quote: "General Policy Requirements for Trust Service Providers" ## 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 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 Revocation, OCSP, and CRL Operations](/artifacts/global/etsi-en-319-411-1/revocation-ocsp-and-crl-operations.md): Operate ETSI EN 319 411-1 revocation status services with CPS procedures, authenticated requests, 24-hour CRL or OCSP publication controls, and audit evidence. - [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. *Recommended next step* *Placement: after practical guidance* ## Operationalize certificate re-key controls Map the re-key trigger, CP/CPS rule, subscriber evidence, certificate lifecycle logs, and revocation or key-changeover records into accountable control work. - [Assess certificate re-key evidence](/solutions/assessment.md): Turn ETSI EN 319 411-1 re-key requirements into control owners, artifacts, and review checkpoints. - [Research a re-key edge case](/solutions/research-copilot.md): Use cited support when re-key overlaps with revocation, attribute changes, or CA key changeover. - [Talk through ETSI EN 319 411-1 re-key implementation](/contact.md): Review CP/CPS wording, evidence gaps, and certificate lifecycle controls with Sorena. --- [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/faq/re-key