Guidelines for Certification Authorities



This guideline is prepared for EUMED countries, large regions or international organizations for accreditation of their Certificate Authority. The definitions and information are gathered together from the documents of EUGRIDPMA and CAOPS WG.




The EUGridPMA is the international organisation to coordinate the trust fabric for e-Science grid authentication in Europe. It collaborates with the regional peers APGridPMA for the Asia-Pacific and The Americas Grid PMA in the International Grid Trust Federation. The charter document defines the group's objective, scope and operation. It is the basis for the guidelines documents on the accreditation procedures, the Authentication profile for X.509 secured “classic” certification authorities and other IGTF recognised Profiles.

EUGridPMA Charter

The Charter defines the policies, practices, and bylaws of the European Policy Management Authority for Grid Authentication in e-Science. The Charter is owned and managed by the EUGridPMA.

Certification Authority(CA)

The entity or system that signs X.509 identity certificates.

Certificate Policy (CP)

A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements.

Certification Practice Statement (CPS)

A statement for the practices, that a certification authority applies in its operations.

Certificate Revocation List (CRL)

A time stamped list displaying revoked certificates that are signed by a CA and made freely available in a public repository.

PKI (Public Key Infrastructure)

IT infrastructure that enables users of a basically unsecured public network (such as the Internet) to securely and privately exchange data through the use of a public and a private cryptographic key pair that is obtained and shared through a trusted authority.

Private Key

In secure communication, an algorithm pattern used to encrypt message that only the corresponding public key can decrypt. The private key is also used to decrypt messages that were encrypted by the corresponding public key.

Public Key

The pattern used to confirm “signatures” on incoming messages or to encrypt a file or message so that the holder of the private key can decrypt the file or message.

Registration Authority (RA)

An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates.

Relying Party

A recipients who accepts a digital certificate and digital signature.


In the case of certificates issued to resources (such as web servers), the person responsible for the certificate for that resource. For certificates issued to individuals, same as certificate subject.


Membership Request

A community or organisation can apply for membership by sending a request to the PMA Chair. Such requests should come from:

- Authorities that intend to join the common trust domain; or

- Major relying parties, as defined in section 3 of the EUGridPMA Charter

Membership can be granted and authorities accredited only in face-to-face PMA meetings, and then only after an in-person appearance of a representative of the membership applicant.

Accreditation process

The PMA will accredit Authorities based on the positive outcome of an initial review with respect to all relevant guideline documents, and a successful registration process.

At the start of the acceptance process, the prospective members request the PMA Chair to join the CA mailing list by This e-mail address is being protected from spambots. You need JavaScript enabled to view it .fr sending a mail to the PMA Chair. The prospective member then sends the CP/CPS document around to the other members for comments. The chair will then ask two PMA members to review that CP/CPS in detail. If the first version has obvious inconsistencies, the chair may defer appointing the referees until the appropriate changes have been implemented.

After sufficient iteration a CP/CPS is considered ready for presentation at the next PMA meeting. At that meeting, it should be presented in person to the PMA and the most critical points of the CP/CPS - explain the authentication and vetting procedure and the physical security measures, record persistency, procedures and such - must be detailed.

Based on the implemented recommendations of the assigned reviewers and the discussion in the meeting, the prospective member may either be approved immediately by the PMA, or this may be deferred until the recommended changes are implemented. In the latter case, the final CP/CPS must be sent to the full mailing list and a two-week voting period must ensue.

Registration process

Before an accredited CA to be included in the repositories of the PMA the relevant introduction ceremonies must have been completed successfully.

The following information must be conveyed to the PMA Chair – by a trusted means if required due to the nature of the information. Such details are to be described in the guideline documents, but will include at least:

- Name of the person representing the Authority in the PMA and possibly an alternate;

- contact information;

- geographical and community scope of the Authority;

- CP and CPS document(s) and a link to where the CP/CPS will be made available to interested parties;

- fingerprint(s) of the source of trust or root certificate;

The introduction process is not complete until all the information above has been conveyed to the PMA.


After approval and after the possible voting period has completed, the Authority will be included in the membership list. The PMA Chair or any other person on the Chair’s behalf will distribute the RPM with the root certificates, the signing policy files, and the CRL distribution point, and the CA will be linked from the site.


Changes in the policies, practices and in the name space may void the accreditation unless approved by the PMA. A planned major change in policy, practice or namespace must thus be submitted to the PMA for approval. Complaints should be registered within a reasonable time after announcing the changes.


You should take into considerations the following technical actions in your CA installation and certificate operations such as certificate request, certificate revocation list, and publications of certificates.

CA Installation

The following action will be take place in your CA installation:

  • Assign a servers hardware for your CA software: This server will be dedicated machine for CA system, you should determine its hardware components according to software needs of the CA.
  • Decide to manage on-line or off-line CA: The CA system must be completely off-line or use at least a FIPS 140-2 level 3 Hardware Security Module or equivalent to protect the private key of CA, you should decide to manage an off-line CA or an on-line CA which uses the defined protections for private key of CA. You can take more information from “Authentication Profile for Classic X.509 Public Key Certification Authorities with secured infrastructure” document.
  • Decide to use CA manager software: There are many choices about CA manager software. You can research and decide to use one of the software. The known and free CA software are:
  • Define the role of RAs and if needed decide to use RA components: A CA must define the role of RA, and these RAs are responsible for the identity vetting of all end-entities (users, admins who is responsible from servers, admins who is responsible from services). If it is needed install and use RA components of CA software.

Issuing CA Certificate

  • Decide properties of CA key: A CA key must have minimum length of 2048 bits and must be configured for long term use. If the private key of the CA is software-based, it must be protected with a pass phrase at least 15 elements.
  • Decide to use certificate extensions: The CA and end-entity certificate extensions should be determined according to “Grid Certificate Profile” and “Authentication Profile for Classic X.509 Public Key Certification Authorities with secured infrastructure”
  • Decide the CA certificate DN: The DN of the CA certificate should define the CA manager properties such as country, organisation, organisation unit and common name of the CA. Before creating the CA certificate, be sure of CA certificate DN.

CA/RA Operational Guidelines

After the installation of CA software, prepare an operational guideline for CA and RA technical operations for designated personnel of the CA and RA.

CA On-line Repositories

The followings must be published by each authority for their subscribers, relying parties and for benefit of distribution by the PMA and federation:

  • The CA root certificate
  • A http or https URL of the PEM-formatted CA certificate
  • A http URL of the PEM or DER formatted CRL
  • A http or https URL of the web page of the CA for general information
  • The CP and/or CPS documents
  • An official contact address for inquiries and fault reporting
  • A physical or postal contact address
  • The repository must be run at least on a best-effort basis, with an intended continuous availability.

If you decide to take certificate request from the on-line repository, you should prepare an https URL for user, host and service certificate requests.


There should be a single CA organization per country, large region or international organization. The goal is to serve the largest possible community with a small number of stable CAs. To achieve this sustainability, it is expected that each CA will be operated as a long-term commitment by institutions or organizations rather than being a bound to specific projects.

The CA will handle the actual task of issuing the certificates and certificate revocations lists. The CA must prepare a CP/CPS and should document the each step of operations in detailed.

Preparing CP/CPS

Every CA should have a CP/CPS and these documents should be structured as defined in RFC 3647 ( Every CA organization must publish their CP/CPS documents in an on-line repository, you can search and find every accredited CA CP/CPSs on web pages and use them as an example is they are structured as defined in RFC 3647.


Every CA must assign its CP/CPS an O.I.D. You can request an O.I.D. from IANA (

Self Audit Guidelines

You can check your technical actions and CP/CPS document with “Check Lists for new CA Organization” document in EUMEDGRID-Support project wiki page and “Guidelines for auditing Grid CAs Version 1.0” document in CAOPS WG (CA Operations Working Group) web page (


1. Authentication Profile for Classic X.509 Public Key Certification Authorities with secured infrastructure, Version 4.2

2. Guidelines for auditing Grid CAs, Version 1.0

3. Grid Certificate Profile

4. Policy on entities that are natural persons

5. Policy on vetting identity by a face to face meeting

6. Policy on vetting identity by a Trusted Third Party

7. Policy on holding non-exportable private keys protected on a secure hardware token

8. Policy on holding private keys protected on a secure hardware token

9. Policy on holding private keys protected in files

10. Accreditation Procedures

11. Protection of private key data for end-users in local and remote systems


We have 85 guests online

We use cookies to improve our website and your experience when using it. Cookies used for the essential operation of the site have already been set. To find out more about the cookies we use and how to delete them, see our privacy policy.

I accept cookies from this site.

EU Cookie Directive Module Information