Certificate Profile Fields

The following lists available Certificate Profile Fields.

For more information on Certificate Profiles, see the Certificate Profiles Overview and for information about how to manage Certificate Profiles, see Certificate Profiles Operations.

Available Key Algorithms

List of allowed key algorithms that public key used in the certificate requests must comply with.

Note that RSA includes both rsaEncryption and RSASSA-PSS as defined in RFC4055.

Available ECDSA Curves

List of allowed named curves. Select Any allowed by bit lengths to additionally allow any curve matching the selected bit lengths restriction.

Available Bit Lengths

List of allowed key sizes that public key used in the certificate requests must comply with. Currently, this validation only checks that the used key's size is within the interval of the lowest and highest selected value. Select 0 bits for implicit EC curves.

Validity

The validity determines the end date of the issued certificates and can be configured as:

• fixed date with ISO8601 format 'yyyy-MM-dd HH:mm:ssZZ', i.e. '2017-06-03 18:15:00+00:00', or
• relative time in terms of years, months, days, hours, and seconds in the form '*y *mo *d *h *m *s', i.e. '2y-10d'

For a relative validity, the end date of the certificate is calculated by its start date plus the value configured. The start time usually is the time point of issuance (i.e. if no offset for the start time is configured).

Years are always translated as 365 days and months as 30 days.

The field notAfter in the issued certificate will have the value 'now + validity days'. It can also, if noted in the field, be entered in terms of years, months, and days. For instance '10y 9mo 8d' is translated to 10 years, 9 months, and 8 days from now. Instead of the validity period, an absolute end date could specify the end of the validity period. This date should be given in the format 'yyyy-MM-dd HH:mm:ssZZ', for example, the date 'June 3rd, 2017 at 6:15 PM' in UTC should be given as '2017-06-03 18:15:00+00:00'.

The Allow Validity Override option allows requesting a specific notAfter date. This is currently possible when using CMP (the CRMF request format) when using the API to issue certificates, or by using the enrollment page on the RA web.

The validity of a certificate is determined as follows:

• The Validity field in the profile specifies the maximum allowed validity, which will be the validity if nothing else is specified.
• If 'Allow validity override' is enabled in the profile, the profile value can be overridden with:
  • Start and end time specified when adding the end entity, if allowed in the End Entity Profile.
  • Requested validity from the certificate request (CMP for example).

Constraints

The following constraints apply for the validity of a certificate issued by the CA.

notBefore

• notBefore is normally 10 minutes before the current time, to avoid problems with clocks that are a few minutes out of sync (see Validity Offset below).
• notBefore can be set to any desired value if allow validity override is enabled, except for the limitation concerning notAfter.

notAfter

• notAfter can never be before notBefore.
• The notAfter time of issued certificates can never be longer than the validity time specified in the certificate profile used.
• The notAfter time of issued certificate can never be longer than the CAs own validity.
• notAfter can not be set prior to a time before issuance unless the certificate is being issued as revoked or being used as a link certificate. 

If the validity is for a CA the certificate profile specifies the maximum validity, but it can be shorter if specified when adding the CA. The validity of the CA can never be longer than the value specified in the profile.

The last option you have is to set a global maximum validity date for certificates issued from the EJBCA instance. You can do this by setting the option 'ca.toolateexpiredate' in ejbca.properties. See the documentation in conf/ejbca.properties.sample for more details. If a validity period would exceed this value, if it is configured, an error occurs, and no certificate is issued.

Undefined Validity

There is a part in section "4.1.2.5. Validity" of RFC5280 that specifies a date to be used to indicate that a certificate has no well-defined expiration date: To indicate that a certificate has no well-defined expiration date, the notAfter SHOULD be assigned the GeneralizedTime value of 99991231235959Z.

You can set this in EJBCA as follows:

1. Update cesecore.properties setting the ca.toolateexpiredate. This is a global setting, so keep in mind all CAs, etc would be able to use super-long expiration date!
2. Create a new CA certificate profile with validity set to 9999-12-31 23:59:59+00:00.
3. Create a new CA with validity set to 9999-12-31 23:59:59+00:00 using the CA profile created in the previous step.
4. Create a new end entity certificate profile with validity set to 9999-12-31 23:59:59+00:00.
5. Create a new end entity profile that uses the certificate profile created in step 4.
6. Add new end entities and issue certificates for them.

Short Lived Certificates

In a Certificate Profile, you can configure validity down to minutes. Also using validity override and requesting a specific validity time through the protocols and APIs (WS, REST, CMP, EST, SCEP) short times can be requested, down to minutes and seconds. When using shorter validity periods than what is configured in the Certificate Profile, the value in the profile will function as an upper limit. Longer times than that is not possible to issue.

Validity Offset

A validity offset (used for setting back or forth start date to handle clock skew) can be configured in the certificate profile as a relative time in the form of '*y *mo *d *h *m *s'. With this, the certificates default offset (specified in cesecore.properties '-10m') will be overwritten.

If a fixed end date in the form '2016-10-09 14:41:39+01:00' is used as certificate validity, only the start date of the certificate will be offset. 

If a relative time in form of '*y *mo *d *h *m *s' is used as certificate validity, the start and end date of the certificate are offset. 

Example: Use the value '-5m' to have a notBefore date that is 5 minutes before the current time, to be valid on relying parties if their clocks are a bit behind.

Expiration Restrictions

Expiration restrictions can be configured in the certificate profile to not let the user certificates expire on certain weekdays, but before or after.

If a fixed end date in the form '2016-10-09 14:41:39+01:00' is used as certificate validity, the restriction is applied after saving the certificate profile and a user message with the new fixed end date is shown.

If a relative time in form of '*y *mo *d *h *m *s' is used as certificate validity, the restriction is applied during certificate issuance if it does not conflict with other restrictions (i.e. time nesting with the SubCA certificate).

Profile Description

Use the Profile Description field to give the Certificate Profile a freeform description. The description you specify will be displayed in the RA Web Make New Request page (Enroll > Make New Request) next to the chosen Certificate Subtype. 

Allow Extension Override

If extension override is allowed, X509 certificate extensions featured in certificate requests are honored, otherwise, they are ignored. Externally supplied extensions are added to certificates "as-is". In the case such an extension is already defined in the certificate profile (i.e. having the same OID), the definition in the profile will be overridden including the criticality flag.

A client or EJBCA alias operating in RA mode can still register an end entity with certificate extension content extracted from the CSR, without enabling Allow Extension Override, as long as the end entity profile permits it.

Note that no validation of the actual content of the certificate extension is done. As a consequence, this option should only be used when you know that the request comes from a very trusted source. Such a trusted source is normally an external RA.

Only use this option when the certificate request comes from a trusted source.

To control in detail which extensions can be overridden, and which cannot, the optional text field Overridable extension OID list and the option Extension list is disallowed can be used. The field should contain a comma-separated list of OIDs, for example 2.5.29.17,2.5.29.32. This is used to give RAs some control over the content of certificate extensions, while still enforcing policy for critical parts, to ensure an RA cannot (accidentally) issue invalid certificates. For example, you may allow an RA to control the SubjectAlternativeName extension, but not the KeyUsage or CertificatePolicies extension.

• If Overridable extension OID list is not empty and Extension list is disallowed is cleared, only extensions with OIDs on this list can be overridden (allow list).
• If Overridable extension OID list is not empty and Extension list is disallowed is selected, all extensions can be overridden except the listed ones (block list).
  
  

Allow Subject DN Override by CSR

If subject DN override is allowed, the X509 subject DN created in a certificate can come directly from the CSR in the request sent by the user. This is instead of the usual way in which the user's registered DN is used.

A client or EJBCA alias operating in RA mode can still register an end entity with the subject DN extracted from the CSR, without enabling Allow Subject DN Override by CSR, as long as the end entity profile permits it.

Using this option you can create certificates with very strange DNs, or with DNs in very specific orders.

Note that no validation of the actual content of the subject DN is done. As a consequence, this option should only be used when you know that the request comes from a very trusted source. Such a trusted source is normally an external RA.

Only use this option when the certificate request comes from a trusted source.

Allow Subject DN Override by End Entity Information

If subject DN override is allowed, the X509 subject DN created in a certificate can come directly from the request meta information sent by the user. This is instead of the normal way where the user's registered DN is used. 

Using this option you can create certificates with a very specific ordering of subject DN fields. Note the following:

• The provided subject will still have block-listed characters and white spaces removed.

• '+' is escaped since multivalued RDNs are not supported.

• RDNs with empty attribute values will be removed.

• Names have to comply with the CeSecore naming style (e.g. SURNAME=... instead of SN=..).

This option should only be used when you know that the request comes from a very trusted source (RA) over EJBCA's web service "certificateRequest" call. In this case, the SubjectDN of the UserDataVOWS object will be used without modification.

If Allow subject DN override by CSR is also specified, the CSR's subject DN will be used when present.

Allow Certificate Serial Number Override

The generated certificate serial number could be overridden if Allow certificate serial number override is enabled in the used certificate profile.

If using the CA UI for creating entities, you must also add Custom certificate serial number to the used end entity profile.

With web services, use the 'setCertificateSerialNumber' for your 'UserDataVOWS' user.

With External RA (ExtRA), the CertificateRequestRequest takes a certificate serial number as a parameter.

Note that the row 'serialNumber' number in the 'CertificateData' database table must have a unique index for this feature to work. Normally you use an index for unique issuerDN, serialNumber. Without an index, the feature is automatically disabled.

create unique index certificatedata_idx1 on CertificateData (issuerDN,serialNumber);

If you run the WS stress test of clientToolBox you can specify that the test should use 'setCertificateSerialNumber'. A new random serial number will then be used for each created user. The java system property 'maxCertSN' specifies the number of bits to be used in the serial number.

After creating the index a restart of the application server is required for the database change to take effect.

Example:

JAVA_OPT="-DmaxCertSN=16" $EJBCA_HOME/dist/clientToolBox/ejbcaClientToolBox.sh EjbcaWsRaCli stress WsCA1 20 2000 wsCreatedUser wsCreatedUser

Allow Backdated Revocation

Revocation information of a revoked certificate contains the date and time from which the certificate is not valid (the revocation time). Normally the revocation time is set to the time of the revocation. Enabling Allow Backdated Revocation allows setting an earlier time when revoking a certificate from the profile, so-called backdated revocation. Backdated revocation is also supported for changing the revocation reason for previously revoked certificates.

You can backdate revocations using the EJBCA REST API /revoke endpoint or the Web Service interface, either by using the WS API call revokeCertBackdated in your application or using the Web Services CLI.

• Do not enable this feature if the profile will be used by a CA that is issuing delta CRLs.
• With the Allow Changing Revocation Reason setting enabled on CA level, the revocation reason change will not end up in the next Delta CRL if the revocation is backdated beyond the previous full CRL. 

Use Certificate Storage

Issued certificates are stored in the database to be able to provide them upon request or provide revocation information. Certificate storage can also be turned off in the CA settings, creating Ephemeral Certificates (also known as Throwaway Certificates). Setting either setting to false will lead to certificates not being stored, not even meta information.

The certificate storage is enabled by default.

If EJBCA is used as a certificate factory, where the functionality of the CA UI is not required, certificate storage can be disabled to improve performance. For more information, see Maximizing Performance.

Disabling this setting will prevent features that depend on the actual certificate data being present from working. This setting is by default enabled and should not be modified unless understood well.

Note that EJBCA does not validate the path length constraint field at the time of issuance, and does not prevent you from creating invalid certification paths (for example, by issuing a CA from another CA with pathLenConstraint = 0).

Key Usage

The Key usage extension defines the suggested purpose of this certificate. For users, certificate usage is often separated in certificates used for signatures (Digital signature and Non-repudiation), and certificates used for encryption (Key encipherment and Data encipherment).

For CA certificates, Key Usage is normally set to Key certificate sign and CRL sign.

The fixed profiles have sensible defaults. For more information, refer to RFC 5280.

Forbid encryption usage for ECC keys: This flag enables selecting both RSA and ECSDA key algorithms in the Certificate Profile. When selected Data Encipherment and Key Encipherment key usages will be disabled for ECDSA during certificate creation. 

Allow Key Usage Override

Enable to allow users to over-ride the key usages defined in the profile when requesting a certificate. Enabling Allow Key Usage Override allows having one certificate profile, but still issue certificates for different purposes. Leave it disabled unless you are sure what you are doing.

Extended Key Usage

The meaning of Extended key usage is defined in RFC5280. Normally the values specified in the fixed certificate profiles are good for the usage the fixed profile is for.

You can define your own extended key usages on the Admin Web System Configuration page. Select the Extended Key Usages tab and add your custom extended key usage's OIDs and readable name. After adding the new key usage, it can be chosen in the Edit Certificate Profile page. For more information, see Extended Key Usages.

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 in the form of an OID: 2.5.29.32.0

The OID 2.5.29.32.0 is the 'anyPolicy' as defined by RFC 5280. If you make your own policy you must create your own OID, constructed from an 'Enterprise Number' assigned by IANA. Getting an Enterprise Number is free, and you can get it from IANA.

For example, the PrimeKey enterprise number is 22408 and an OID can be constructed like 1.3.6.1.4.1.22408.1.1.1.1. Here 1.3.6.1.4.1 is IANA standard prefix, PrimeKey is 22408 and the following stands for products->ejbca->attibutes->ejbcaDeviceCertificate. The numbers after 22408 are defined by PrimeKey.

To add both the User Notice and CPS URI policy qualifiers to the same policy OID, add the policy OID twice, once with the User Notice qualifier, and once with the CPS URI qualifier. In the certificate, it will be encoded with both qualifiers under the same OID (as per RFC5280).

Issuer Alternative Name

Using the Issuer Alternative Name extension copies the Subject Alternative Name value from the issuing CA certificate and places it into the certificate produced.

Usage examples:

• Use the Issuer Alternative Name extension to create a CA with Subject Alternative Name "rfc822Name=ca@org.org" and including that in the CA certificate. If you include Issuer Alternative Name in the certificate profile used to issue end entity (or sub CA) certificates, the end entity certificates will get Issuer Alternative Name "rfc822Name=ca@org.org". The end entity certificates can have a different Subject Alternative Name, as this is registered for the specific end entity.
• Add subject and issuer alternative name with a DirectoryName to a Root CA by setting the value for Subject Alternative Name to "DirectoryName=L=SWE\,ST=FOO", thus with the comma escaped.

CRL Distribution Points 

The CRL Distribution Point (CDP) extension provides information for clients verifying a certificate. The value is a URI that points to a CRL that can be used to check if the certificate is revoked. The CRL is issued by the CA. There are different kinds of CRL Distribution Points and currently, EJBCA supports a URI.

Note that you are responsible for the order and encoding of your CRLIssuer. If this is important - check it!

 A CRLDistributionPoint for a CA in EJBCA could look like:

http://host:port/ejbca/publicweb/webdist/certdist?cmd=crl&issuer=url-encoded-issuerD

such as the link from the web distribution pages

• host is the DNS name by which the CA is accessible. Port 8080 is the default port that JBoss listens to, but if you changed the JBoss port, this value should also change.
• url-encoded-issuerDN is the CAs common name as configured when the CA was created. This is the same DN as occurs as Issuer in certificates issued by this CA.

When configuring this extension you should take the URI entered and test it in a normal browser, from another machine than the CA, to see that it works before issuing any certificates.

It should also be possible to use an LDAP distribution point, if you have configured a publisher to publish CRLs to LDAP:

ldap://yourLdapServer:port_number/cn=CA-test,ou=CRLPUB,dc=mycompany,dc=com?certificateRevocationList

By selecting Use CA defined CRL Distribution Point you can configure the CRL distribution point in the edit CA page instead, and use this value in every certificate profile that uses that CA. It is a convenience function, so you do not have to enter the same CDP in all certificate profiles.

It is possible to configure multiple URLs for CDPs if they are separated by ';'. For example: http://cdpurl-1/mycrl.der;http://cdpurl-2/crl.crl

The same applies to CRLIssuer, for example: CN=Foo,C=SE;CN=Bar,C=US

Note that if a URI contains a ';' it has to be double-quoted. For example, if you have two URLs:

• http://cdpurl-1/mycrl.der
• http://cdpurl-2/getcrl;binary

You could then put them together as: http://cdpurl-1/mycrl.der;"http://cdpurl-2/getcrl;binary"

CRL Issuer

According to RFC5280, a CRL issuer is:

An optional system to which a CA delegates the publication of certificate revocation lists;

Freshest CRL

The Freshest CRL extension (also called Delta CRL Distribution Point) is used for Delta CRLs. How to issue delta CRLs is explained in CA configuration. The freshest CRL extension identifies how delta CRL information is obtained. The same syntax is used for this extension and the cRLDistributionPoints extension.

 From RFC5280:

The freshest CRL extension identifies how delta CRL information is obtained. The extension MUST be marked as non-critical by conforming CAs. 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.13. The same conventions apply to both extensions.

OCSP Service Locator

This extension is used when revocation information for the certificate containing this extension is available using the Online Certificate Status Protocol (OCSP) [RFC6960] (former RFC2560). The URI field is the location of the OCSP responder, using the conventions defined in RFC6960, usually a plain URL such as http://ocsp.company.com/. The default URL for the internal OCSP responder in EJBCA is http://hostname:8080/ejbca/publicweb/status/ocsp.

OCSP No Check

Selecting this option includes the extension id-pkix-ocsp-nocheck as defined in section 4.2.2.2.1 of RFC6960 in certificates issued using this certificate profile.

CA Issuer URI

This value is used for the Authority Information Access CRL extensions field CA Issuer as specified in RFC5280 (section 5.2.7).

The URIs specified in this semi-colon separated list must point to files containing either a single certificate (.cer or .der) or a collection of certificates (.p7c).

Use LDAP DN Order

In a certificate, the order of the DN components (CN,O,C etc) can be put in a different order, in the binary encoded certificate.

• last-to-first, forward (historically called LDAP DN Order in EJBCA): CN=Common Name, O=Organization, C=Country

• first-to-last, reverse order: C=Country, O=Organization, CN=Common name

When using the string representation of DNs, the actual order is commonly not displayed, but the tool used will display in the order it sees fit which might be the reverse of the real, binary, order. In order to see the real, binary, order an asn1 parsing tool, like OpenSSL, can be used. In practice DN order can be important as comparisons are often done using string comparisons, where the string value may be depending on the order or not.

The most common order is first-to-last (i.e. C,O,CN), but for historical reasons, EJBCA uses last-to-first (CN,O,C). Some applications do require first-to-last order however and therefore EJBCA gives you the choice (by clearing LDAP DN order). There are two places in EJBCA where this can be configured:

• In the Certificate profile (Certificate Profiles)
• In the CA configuration (Certificate Authorities)

The relationship between the settings is that they are both evaluated in a logical AND expression. This means that if both are true the DN will have last-to-first (LDAP) DN order, but if any one of them is false the DN will have X.500 order. For references, see RFC2253 and RFC4514.

When using a Custom DN Order, the LDAP DN order setting is also applied by default, defining which component comes first (CN or C for example), regardless of the exact order you specified in the text field. Clear Apply LDAP DN order setting for the Custom DN Order to use the exact order as specified.

Private Key Usage Period

The Private Key Usage Period certificate extension is specified in RFC 3280.

EJBCA calculates the extension's notBefore and notAfter components based on the issuing time of the certificate (cert.notBefore) and the values of the Start offset (startOffset) and Period length (periodLength) fields as follows:

notBefore = cert.notBefore + startOffset
notAfter = notBefore + periodLength

Qualified Certificate Statement

The Qualified Certificate Statement is generally described in RFC 3739 and in ETSI documents. The following fields implement the predefined QC-statement from RFC 3739. See section 3.2.6.1 in RFC 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). Version 2 should always be used.
• Semantics Id: Select semantics ID for natural or legal persons (ETSI EN 319 412-1). EJBCA supports the specification of multiple semantics IDs by adding them as comma separated OIDs. For example:
  • "0.4.0.194121.1.1,0.4.0.194121.1.2" for both Natural- and Legal person.
  • "0.4.0.194121.1.1,0.4.0.194121.1.3", for the id-etsi-qcs-semanticsId-Natural and id-etsi-qcs-semanticsId-eIDASNatural.
• Name Registration Authorities: If present, should contain a name of one or more name registration authorities, responsible for registration of attributes or names associated with the subject (for example rfc822Name=some@example.org,uri=https://example.org). Rarely used.

The next fields implement the QC-statements defined in the Qualified Certificate profile in ETSI EN 319 412-5 / ETSI TS 101 862:

• Use ETSI QC Compliance: Statement claiming that the certificate is a Qualified Certificate (section 5.2.1 in the profile document).
• Use ETSI Secure Signature Creation Device (esi4-qcStatement-4): 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 (esi4-qcStatement-2): Statement regarding limits on the value of transactions. If set, the following fields must be specified:
• Value Limit Currency: For example, EUR, SEK.
• Value Limit Amount: For example, 10000.
• Value Limit Exponent: For example, 0, 1. Total value = amount * 10^exponent.
• ETSI retention period in years (esi4-qcStatement-3). Default value is 0.
• ETSI Type (esi4-qcStatement-6). One of Unused, Electronic Signature (E-Signature), Electronic Seal (E-Seal) or Website Authentication (QWAC).
• Use ETSI QC Legislation Countries (esi4-qcStatement-7). Comma separated list of ISO-3166-2 country codes for countries for the certificate to be classified as qualified certificate by the countries legislation. Allows to specify ISO-3166-2 codes not included in the EU Trusted List as well. Example "CH", or "SE,NO".
  
• ETSI PDS URL and language (esi4-qcStatement-5). Allows to add multiple PDS URL / language pairs. Must be a HTTPS URL. Example, https://www.example.com/respository.
  

The fields for Custom QC-statement String implement 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

A typical eIDAS QC Statement (EN 319 412-5) may consist of:

• id-etsi-qcs-QcCompliance
• id-qcs-pkixQCSyntax-v2
• id-etsi-qcs-QcSSCD
• id-etsi-qcs-QcPDS = www.primekey.com/repository
• id-etsi-qcs-QcType = 0.4.0.1862.1.6.1 (Electronic Signature)
• SematicsID = 0.4.0.194121.1.2 (Legal Person)

PSD2 Qualified Certificate Statement

ENTERPRISE  This is an EJBCA Enterprise feature.

When the Revised Payment Service Directive (PSD2) is implemented, payment services will be required to use qualified certificates for electronic seal and website authentication. The PSD2 QC statement is specified in the ETSI Technical Specification ETSI TS 119 495.

PSD2QcType ::= SEQUENCE{
  rolesOfPSP RolesOfPSP,
  nCAName NCAName,
  nCAId NCAId }
   
RolesOfPSP ::= SEQUENCE OF RoleOfPSP
RoleOfPSP ::= SEQUENCE {
  roleOfPspOid, RoleOfPspOid,
  roleOfPspName RoleOfPspName }

RoleOfPspOid ::= OBJECT IDENTIFIER
RoleOfPspName ::= utf8String (SIZE(256))
NCAName ::= utf8String (SIZE (256))
NCAId ::= utf8String (SIZE (256))

Every PSD2 Third Party Payment Service Provider (TPP) can have one or more of four different roles (described in section 4.2 of TS 119 495). The NCAName and NCAId will be provided by the National Competent Authority (NCA), for example BaFin in Germany.

The other, non PSD2, items in a QC statement are issuer specific, meaning that they are related to the issued, i.e. (Trust Service Provider) TSP, and configured in the Certificate Profile. The PSD2 items however are subject specific and are different in certificates issued to different TPPs. Since a TSP can generate certificates for TPPs in different countries, NCAName and NCAId must also be dynamic values. Because these values change, there is only one ETSI PSD2 QC Statement option in the Certificate Profile and when selected, PSD2 specific data must be registered in the End Entity so that the certificate can be issued with the QC statement information. The PSD2 End Entity information is enabled in the End Entity profiles, and registered when adding/editing the End Entity.

You can also use APIs, like the Web Service API to add the PSD2 QC items. For example, using Web Service with clientToolBox:

./ejbcaClientToolBox.sh EjbcaWsRaCli edituser psd2 foo123 true "CN=PSD2 eSeal Certificate,organizationIdentifier=12345678-9876,O=PrimeKey,C=SE" NULL NULL ManagementCA 1 PEM NEW User Client NULL  NULL NULL "QCETSIPSD2ROLESOFPSP=0.4.0.19495.1.1;PSP_AS" "QCETSIPSD2NCANAME=PrimeKey Solutions AB, Solna Access, Plan A8, Sundbybergsvägen 1, SE-17173 Solna" "QCETSIPSD2NCAID=SE-PK"

Certificate Transparency

ENTERPRISE  This is an EJBCA Enterprise feature.

For details on Certificate Transparency, see Certificate Transparency

This is a module in EJBCA Enterprise Edition that implements Certificate Transparency (CT) as specified in RFC 6962. The purpose of CT is to create public audit logs of all certificates issued by the public SSL/TLS CAs. The presence of audit records is planned to be required for EV certificates in Google Chrome from February 2015 (and other web browsers and non-EV certificates later on as well). Note that CT is only relevant for CAs issuing public SSL/TLS certificates; other types of CAs should not use CT. For more information, refer to the CT website.

The following options are visible if the CT module is available (In EJBCA Enterprise Edition):

• Use in new certificates: During certificate issuing, whether EJBCA should submit a pre-certificate to CT logs and include the resulting SCTs in the certificate.

• Use in OCSP: Whether EJBCA should submit certificates and fetch SCTs from CT log during OCSP requests, and include the SCTs in an OCSP response extension.
• Use CT publishers: Whether certificates should be published by the CTCustomPublisher. A publisher of the type CTCustomPublisher must be created and enabled in the certificate profile.

Depending on which of the options above are enabled, one or more of the following options may appear:

• Enabled CT Labels: Which labels to submit to and obtain Signed Certificate Timestamp (SCTs) from. Each label contains a set of CT logs. At least one log from each selected label will be submitted to. New logs and labels can be added in the System Configuration, see Certificate Transparency.
• Minimum number of SCTs: If fewer servers respond with an SCT than this number, the underlying operation will fail (certificate issuing or generation of an OCSP response extension).
  • By Validity: Automatically sets the number of minimum SCT responses based on the validity of the certificate. The value is determined by the CT Policy for Chrome (May 2016).
  • Custom: Specifies the minimum number of SCT responses manually. This value cannot be less than the number of selected labels since at least one CT log from each label will be written to and expect a response
• Maximum number of SCTs: After having received this number of SCTs, EJBCA will stop contacting log servers.
  • By Validity: Sets the number of maximum SCT responses by validity i.e. maximum = minimum. This ensures that no more SCTs than required will be included in the final certificate
  • Custom: Specifies the maximum number of SCT responses manually. This value cannot be less than the number of selected labels since at least one CT log from each label will be written to and expect a response.
• Submit existing certificates: If existing certificates (defined as not already having an SCT) should be submitted to CT logs during OCSP responses or publishing.
• Number of retries: If a log server times out it will be tried again after all other logs have been tried. This is the maximum number of tries per server.

ITS Certificate Profile Type

ENTERPRISE  This is an EJBCA Enterprise feature.

For more information, see C-ITS ECA Overview and Managing C-ITS ECAs.

Application Permissions

Like the key usage field in X509 certificates, appPermissions defines the intended use of the certificate. ETSI, IEEE, and CPOC describe pre-defined values for this depending on certificate use. For example, an ITS-S enrollment credential would have different appPermissions than an EU-level Root CA.

Certificate Issuing Permissions

Similar to appPermissions, Certificate Issuing Permissions restricts what kind of certificate a CA can issue. For example, an EA can only issue enrollment credentials but not authorization tickets.

Both appPermission and certIssuePermissions are associated with SSPs, Service Specific Permissions. EJBCA does not specify SSPs appPermissions in EA and accepts the SSP requested by ITS-S on an allowed Application Object Identifier (AID). It specifies default SSP values in table 6 of the C-ITS Point of Contact (CPOC) Protocol release 1.2 in certIssuePermissions in EA signed certificate request.

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.

Microsoft ObjectSid Security Extension

ENTERPRISE  This is an EJBCA Enterprise feature.

The Use Microsoft ObjectSid Security Extension allows the addition of the szOID_NTDS_CA_SECURITY_EXT flag for certificates in Microsoft environments as mitigation of CVE-2022-26931. As the extension is added by default, all certificate profiles have this setting enabled by default. Note, however, that the extension is only added to certificates that have been enrolled through Microsoft Auto-enrollment. It is also possible to disable the extension through the msPKI-Enrollment-Flag at the MS template. However, an administrator must disable it at the certificate profile level in the current EJBCA implementation. This flag does not affect any operations where the same extension is configured in custom extensions in EJBCA.

Document Type List

The DocumentTypeList extension is used to indicate the document types (as contained in the MRZ) that the corresponding document signer is allowed to produce. The list should be separated with a comma ','. For example: "P", or "P,ID"

See ICAO MRTD Technical Report LDS and PKI Maintenance for reference.

Card Number 

Select this if you want to use the SEIS Cardnumber Extension. The card number is a unique identifier stored in the certificate and should also be printed on top of the card on which the certificate is stored. When used, the card number needs to be set for the end entity before creating a certificate. The extension is specified in the Seis document SS 614331 chapter 4.3 and has OID 1.2.752.34.2.1.

Subset of Subject DN

By using a subset of Subject DN in the certificate you can register users with more information than is present in the issued certificate. Example:

• Use "Subset of Subject DN" in a certificate profile, with selected values CN,O and C.

• Register an end entity with "CN=Tomas Gustavsson,O=PrimeKey,OU=Ignored,C=SE", and the configured certificate profile.
• Issue a certificate using the certificate profile.
• Issue a certificate. The issued certificate will contain subject DN "CN=Tomas Gustavsson,O=PrimeKey,C=SE".

Do not use a Subset of Subject DN when issuing CA certificates. That can have undesired consequences, such as colliding CAIds and inability to find CA certificates.

Available CAs

Select which CA's are authorized to issue this certificate profile. Use this setting to permit specific CA's to issue this certificate profile when there is a requirement to only allow a specific CA to issue the certificate profile. One example where this is used is for allowing a specific Root CA to only issue a Sub CA certificate profile. The default setting is to allow issuance from Any CA.

Single Active Certificate Constraint

This value adds the constraint that only a single active certificate may exist for an end entity at any point in time. Issuing a new certificate for an end entity using this constraint automatically leads to the revocation of any unrevoked and unexpired previous certificates. Revocation reason will be set as "Superseded".

This configuration value is only available for End Entity Certificate Profiles.

Account Binding Namespace

Binding a certificate to an identity defined outside of EJBCA can be useful if you want to use a UID from a customer database, or an externally defined organization identifier for a device certificate. In EJBCA, this is supported using External Account Bindings, which allow the submission of an externally defined value during the enrollment process. Namespaces are used to group External Account Bindings and are configured in the EJBCA System Configuration, see External Account Bindings.