|
Table of Contents
|
Some hints when adding CAs
- First create a new [CertificateProfile] for the new CA, using ROOTCA or SUBCA as a template. If you don't create a new certificate profile you will find it hard to change the certificate contents of your CA when you find out that you need an extension, for example a CDP.
CA attributes
Some of the attributes in the add/edit CA page are simle why some are more complex.
The more complex ones are usually related to X.509 certificate extensions. A brief overview willbe given here, but these 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.
Warning
Specifically, you should really check the contents of your certificate, that it fulfills your desires before going into production.
CA Token Type
Soft
This is where the CAs signing keys (and encryption keys) are stored. By default they are stored in an encrypted PKCS#12 file in the database. This is the Soft keystore type.
The Authentication code is the encryption passphrase for the PKCS#12 file. If you don't enter an authentication code, the default one configured in conf/ejbca.properties in property 'ca.keystorepass' is used.
If you check 'Enable auto-activation of CA token' the passphrase is stored, in obfuscated form, in the database so that the CA token can be activated automatically when the server starts.
If you use the default authentication code, auto activation is always enabled.
If you do not check auto-activation you will have to manually go in and activate the CA token after a server re-start. This is done in 'Basic Functions->View Information, or in the CA activation page'.
The technicalities behind the autoactivate checkbox is the following:
- If you enter a password and check the auto-activate button, the password is stored (in encrypted/obfuscated form) as a 'pin' property, identical to how auto activation works for hard CA tokens.
- If you don't enter a password, it is therefore impossible to enable auto activation.
- When starting a CA with soft CA token, the code check to see if there is a 'pin' property. If not it tries the default password from ca.keystorepass in ejbca.properties.
PKCS#11
If you choose the PKCS#11 token type when creating a new CA you can keep the CAs keys in an HSM. For more information hwo to configure an HSM, see the User Guide at http://ejbca.org/, http://ejbca.org/manual.html#Hardware%20Security%20Modules%20(HSM).
Signing Algorithm
The signing algorithm determines which algorithm the CA certificate will be signed with (if self signed, otherwise the other CA determines this), and also which algorithm certificates issued by this CA will be signed with.
Many different algorithms are supported.
RSA key size
If a signing algorithm based on the RSA key type is selected, this determines the RSA key size of the CAs signing keys. Only available for soft CA Token types, if using a HSM you generate keys of the desired length on the HSM.
ECDSA key spec
If a signing algorithm based on the ECDSA key type is selected, this determines the elliptic curve key specification of the CAs signing keys. This is one of the standard named curves supported by the Bouncy Castle crypto library, see http://www.bouncycastle.org/wiki/display/JA1/Supported+Curves+%28ECDSA+and+ECGOST%29.
Only available for soft CA Token types, if using a HSM you generate keys with the desired spec on the HSM.
Subject DN
The Distinguished Name of this CA. For example:
CN=My Root CA, O=My Organization, C=SE
Signed By
Select here if you want to make a self signed CA, a CA signed by another CA in this EJBCA instance, or an external CA.
When selecting to be signed by an external CA, you will generate a PKCS#10 certificate request to be sent to the other CA for processing. An external CA can be something like Comodo, Verisign etc. Or another instance of EJBCA set up on another server.
Certificate profile
The certificate profile that will be used to generate the CAs certificate. This determines which extensions etc will be present in the CA certificate.
It is recommended that you generate a new (non fixed) certificate profile for your CA. If you do that, you can easily change the certificate contents of your CA by changing the certificate profile and renewing the CA.
Validity days
The desired validity period, in days, of this CA. The real validity time can be limited by other factors, such as maximum validity time in the certificate profile or the validity time of a Root CA that signsthis CA.
Description
Any describing text you want to have displayed for this CA. For example:
"The PIN code for the HSM is in safe ABC in envelope marked CDE".
Use Subject Alternative Name
This gives the possibility to add alternative names to the CA certificate, for example an email. Enter in altName string form:
rfc822Name=<email>, dNSName=<host name>, uri=<http://host.com/>, ipaddress=<address>, guid=<globally unique id>, directoryName=<LDAP escaped DN>
Policy Id
A policy ID you want to use in the CAs certificate. Note that certificate policies are tricky, you should read and understand the certificate policy processing during certificate verification as described in rfc3280.
A root CA may typically have the policy "anyPolicy" which would be entered as: 2.5.29.32.0
Use UTF8 in policy text
Specifies the asn.1 encoding of the the "UserNotice" policy qualifier of the CertificatePolicies extension, if used, in certificates issued by this CA.
The standard states that UTF8String should be used, but Microsoft clients (at least IE6) only handles BMPString, and therefore this is the default encoding.
Select this option to use the standard UTF8String encoding.
Use PrintableString encoding in DN
The standard specifies that DistinguishedNames should be encoded with UTF8String for newer certificates. Some older systems do not support UTF8 though, so by enabling this option the older PrintableString encoding is used instead (if the string can be represented by PrintableString.
PrintableString can only accommodate 7-bit ascii, i.e. a-z, 0-9.
Use LDAP DN order
If checked (default) the DN order of certificates issued by this CA will have the LDAP ordering:
CN=Tomas Gustavsson,O=PrimeKey,C=SE
If unchecked, the DN order of certificates issued by this CA will have the X500 ordering:
C=SE,O=PrimeKey,CN=Tomas Gustavsson
I theory any application should not be sensitive about the order of these strings. In practice it is seldom a problem today either. There are however some legacy applications that will require one order or the other.
Note that this is not necessarily the order displayed when you do for example cert.getSubjectDN().getName() in Java. Different programs decide themselves which order to rpint things in, not necessarily in the encoded order. If you really want to see the encoded order, use 'openssl x509' och 'openssl asn1parse'.
Use Authority Key Id
This controls the AuthorityKeyId extension in CRLs issued by this CA. See rfc3280 for details. You should leave this as the default value.
Use CRL Number
This controls the CRLNumber extension in CRLs issued by this CA. See rfc3280 for details. You should leave this as the default value. A CRL number is an ever increasing number series for every CRL issued, 1, 2, 3, etc.
Use CRL Distribution Point on CRLs
See CertificateProfiles for information about the CRL Distribution Point extension and configuration of this. The CRL Distribution Point can also be included as an extension in CRLs, which is what this field is about.
You can safely leave this field blank.
Default CRL Dist. Point
See CertificateProfiles for information about the CRL Distribution Point extension and configuration of this.
You can safely leave this field blank.
Default CRL Issuer
See CertificateProfiles for information about the CRL Issuer extension and configuration of this.
You can safely leave this field blank.
CA Defined FreshestCRL extension
See CertificateProfiles for information about the FreshestCRL extension and configuration of this.
You can safely leave this field blank.
Default OCSP Service Locator
See CertificateProfiles for information about the OCSP Service Locator extension and configuration of this. Filling this fields gives you the possibility to use the same certificate profile for different CAs with different OCSP Service Locator fields.
You can safely leave this field blank.
OCSP Service
This checkbox enables or disables the built in OCSP service. This OCSP service normally answers to requests directly to the CA, and the OCSP respondes are usually signed with the CAs signature keys. The OCSP service can be configured in conf/ocsp.properties.
XKMS Service
This checkbox enables or disables the built in XKMS service. The OCSP service can be configured in conf/xkms.properties.
CMS Service
This checkbox enables or disables the built in CMS service. The CMS service enables the CA to produce CMS messages (RFC3852, former PKCS#7). This is for example used when downloading signed log files from the "View Log" admin GUI page.
Approval Settings
Approvals is a way to enforce dual (or multiple) authentication for administrators to perform certain actions. The approval settings selects which administrator actions should require approval by several administrators before the action is performed.
Number of Required Approvals
This defines how many administrators must approve another admins actions before it is performed. Setting the number to 1 means that two administrators are needed to perform an action, one who does the initial actions and one that approves the action.
Finish User
Normally (finish user is activated) user passwords function as one-time passwords. When a user gets a certificate, the password is removed and the users status is transitioned from NEW to GENERATED. This is when the user is "finished". If this is deactivated a user can use the password as many times as he/shw wants and get as many certificates as he/she wants.
CRL Expire Period (h)
How many hours a generated CRL will be valid.
CRL Issue Interval (h)
How often a new CRL is generated. You can have CRL expire period set yo 24 hours and CRL issue interval set to 12 hours. This means that a new CRL will be generated 12 hours before the old one expires. 0 means this function is not used.
CRL Overlap Time (min)
How many minutes before the old CRL expires should a new one be generated. If a CRL worker checks every minute to see if new CRLs need to be generated the new CRL will be generated this number of minutes before the old one expires. Useful to ensure that there is no period in time when there is no valid CRL. This might otherwise be the case if the new CRL is generated exactly when the old one expires, but it takes some time to generate new CRLs, or if we only check every 10 minutes to see if a new CRL should be generated.
Delta CRL Period (h)
How many hours a generated DeltaCRL will be valid. Set this value to 0 if delta CRLs should not be used, this is the default.