EJBCA Wiki

Certicate Profile Attributes

Most of the attributes in certificate profiles are complicated and requires a large degree of knowledge about X.509. The attributes are explained in depth in RFC 3280 for the knowledge hungry.

If you don't know what a particular field means, leave it at default. The default are sensible most of the time and follows RFC 3280. The fields that make sense to configure are CRL Distribution point, OCSP Service locator, Certificate Policy, Key Usage and Extended Key Usage and these will be explained a bit more below.

Warning

Specifically, don't add the critical flag to any extensions unless you know exactly what you are doing. This may cause certificate using applications to stop working.

CRL Distribution Point

CRL Distribution Point and CRL Issuer are described in the regular User Guide, under the CRL Generation section..

FreshestCRL

From RFC3280:
[code]
The freshest CRL extension identifies how delta CRL information is
obtained. The extension MUST be non-critical. Further discussion of
CRL management is contained in section 5.

The same syntax is used for this extension and the
cRLDistributionPoints extension, and is described in section
4.2.1.14. The same conventions apply to both extensions.
[/code]

the Use CA Defined FreshestCRL extension works the same way as for CRL Distribution Point.

OCSP Service Locator

The OCSP Service Locator is similar in function to the CRL Distribution Point, except that OCSP is an Online Certificate Status Protocol, meaning that the OCSP service receives a request and sends back a status response saying if a certificate is revoked or not. OCSP Service Locator is also a URI on the form:

http://ejbca-hostname:8080/ejbca/publicweb/status/ocsp

Here ejbca-hostname and port are the same as for CRL Distribution Points.

Testing OCSP is a bit tricky since only Mozilla/Firefox of the common applications have support for OCSP. How to set it up in Mozilla is described in the README file in EJBCA.

Certificate Policies

Certificate Policies indicates which policy a certificate issued with this profile is issued under. Certificate Policies are more described in several RFCs. A certificate policy is on the form of an OID:

2.5.29.32.0

This oid is the anyPolicy as defined by RFC 3280. If you make your own policy you must create you own oid, which should be constructed from an 'Enterprise Number' assigned by IANA. Getting an Enterprise Number is free and you can get it from http://www.iana.org/assignments/enterprise-numbers.

For example. PrimeKeys enterprise number is 22408 and and oid can be constructed like 1.3.6.1.4.1.22408.1.1.1.1. Here 1.3.6.1.4.1 is standard prefix, the ones after 22408 stands for products->ejbca->attibutes->ejbcaDeviceCertificate. The numbers after 22408 is defined by ourselves.

Qualified Certificate Statement

The qualified certificate statement is generally described in RFC 3739. The following fields implements the predefined QC-statement from rfc3739. See section 3.2.6.1 in http://www.ietf.org/rfc/rfc3739.txt?number=3739. RFC3739 does not specify if QC should be critical or not, it may be either

• Use PKIX QCSyntax-v2 - RFC3739 defines an older version (v1 from rfc3039) and a new (v2 from rfc3739)
• Semantics Id - an object identifier, for example 1.2.3.4.5
• RA Name - this component, if present, SHALL contain a name of one or more name registration authorities, responsible for registration of attributes or names associated with the subject (for example rfc822Name=es.yekemirp|ardeifilauq#es.yekemirp|ardeifilauq)

The next fields implements the QC-statements defined in the Qualified Certificate profile in ETSI TS 101 862:

• Use ETSI QC Compliance - Statement claiming that the certificates is a Qualified Certificate (section 5.2.1 in the profile document)
• Use ETSI Secure Signature Creation Device - Statement claiming that the private key related to the certified public key resides in a Secure Signature Creation Device (section 5.2.4 in the profile document)
• Use ETSI transaction value limit - Statement regarding limits on the value of transactions, if this is checked the next three fields must be filled in.
  • Value Limit Currency - e.g. EUR, SEK, etc
  • Value Limit Amount - e.g. 10000
  • Value Limit Exponent - e.g. 0, 1, etc. Total value = amount * 10^exponent

The fields for 'Custom QC-statement String' implements a QC-statement with the following ASN.1:

qcStatement-YourCustom QC-STATEMENT ::= { SYNTAX YourCustomUTF8String
 IDENTIFIED BY youroid }
-- This statement gives you the possibility to define your own QC-statement
-- using an OID and a simple UTF8String, with describing text. A sample text could for example be:
-- This certificate, according to Act. No. xxxx Electronic Signature Law is a qualified electronic certificate

YourCustomUTF8String ::= UTF8String

• Use Custom QC-statement String - Include this custom QC-statement in the QC-statements extension in the certificates.
• Custom QC-statement OID - youroid as defined above, you must define this oid yourself.
• Custom QC-statement Text - the describing text as defined above.

Key Usage

Key usage is an extension defining the suggested purpose of this certificate. For users, it is most often divided in certificates used for signatures (digitalSignature and Non-repudiation) and certificates used for encryption (Key encipherment and Data encipherment). If one certificate is used for all purposes, all these four usage flags should be set.

For CA certificates the usages are normally Key certificate sign and CRL sign.

The fixed profiles have sensible defaults. RFC 3280 explains them in depth.

Allow Key Usage Override

This box should be checked if you want to allow users to over-ride your defined key usages when requesting a certificate. This is currently only possible to do if you request certificates through the API, now with a browser. When checking this is is possible to have one profile, but still get certificates for either signatures or encryption. Normally this should be left disabled.

Extended Key Usage

When is was discovered that some wanted more control on the purpose certificates were used for the Extended Key Usage extension was created. Here it can be tricky since some applications actually requeire some of these extensions. For example Outlook requeires Email Protection to be set in order to allow the certificate to be used to send encrypted email.

The pre-defined profiles have sensible defaults. The pre-defined end user profile should let the certificate be used for mostly anything client related.

Microsoft Template Value

The Microsoft Template Value is a special Microsoft extension used in Domain Controller (AD controller) certificates. It should only be used in certificates issued to Domain Controllers.

Publishers

If you have defined some publishers (LDAP, AD etc) that is usable by this certificate profile, you can select those publishers here. All certificates issued with this certificate profile will be published to (stored in) the selected publishers.

To remove a publisher from the list (remove all for example), hold down 'ctrl' and click on the publisher to de-select it.

Validity

Validity is described in the regular User Guide, under the Certificate Profiles.