ETSI EN 319 411-1 Certificate Services FAQ

ETSI EN 319 411-1 sets policy and security requirements for trust service providers issuing certificates. It is the general certificate-service standard in the ETSI ESI family, and the grounding for this page is V1.5.1 from April 2025.

The standard is not limited to one certificate type. It defines requirements that apply generally and then marks additional requirements for policy families such as LCP, NCP, NCP+, DVCP, OVCP, IVCP, and EVCP. A useful implementation starts by naming the certificate policy, the certificate profile, the relying-party use case, and the CA or RA functions in scope.

A Certificate Policy, or CP, states what rules apply to a certificate for a community or class of use. A Certification Practice Statement, or CPS, explains how the trust service provider operates the service to meet those rules.

That distinction matters in review. The CP anchors applicability and relying-party expectations, while the CPS should connect the policy to operating reality: facilities, trusted roles, key controls, registration procedures, certificate issuance, renewal, re-key, modification, revocation, repositories, and status services.

The evidence should prove the service actually ran under the named CP and CPS during the assessment period. A high-quality file links each certificate policy requirement to the control, owner, system, log, or record that demonstrates the requirement was performed.

For certificate services, the core evidence usually includes CP and CPS versions, certificate profiles, subscriber agreements or terms, identity validation records, RA role records where registration work is delegated, certificate application and issuance logs, revocation and suspension records, CRL or OCSP operation records, repository publication records, CA key management evidence, trusted-role approvals, incident records, and conformity assessment material.

The CA remains the issuing function for certificates, while an RA can support identification, authentication, certificate application, and revocation processes. The practical question is not whether the RA exists; it is whether the CP, CPS, agreements, access controls, and evidence show exactly which registration tasks the RA performs.

A defensible RA setup names the registration officers or trusted roles, the identity proofing method, the approval workflow, the data exchanged with the CA, the confidentiality and integrity protections for registration data, and the records retained for later audit.

Subscribers and relying parties need enough information to decide whether the certificate is suitable for the intended use. ETSI EN 319 411-1 expects documentation such as the CPS, terms and conditions, and PKI disclosure material to explain the certificate type, validation procedure, usage limits, subscriber obligations, revocation contact route, status-checking expectations, applicable agreements, and audit or trust-list context.

This disclosure should be concrete. A relying party should be able to find the CP being applied, the certificate policy identifier, the certificate usage limits, how to check revocation status, and where the TSP publishes the relevant repository information.

eIDAS changes the answer when the certificate service is being positioned as an EU trust service or a qualified trust service. ETSI EN 319 411-1 is still useful for certificate-service controls, but qualified certificate requirements are handled through the qualified-certificate standard and the applicable eIDAS framework.

For public content, avoid saying that EN 319 411-1 alone proves eIDAS qualified status. State the certificate policy, whether the service is qualified or non-qualified, the conformity assessment or supervisory context, and the additional ETSI or legal sources that support the claim.