|
Table of Contents
|
Tutorials
These tutorial movies show administration of EJBCA, both some simple concepts and advanced concepts.
EJBCA Education
Entity Names
DN Fields
The Distinguished Name (DN) was first defined in the X.500 standard and is supposed to be a globally unique name. For normal enterprise CAs we are normally satisfied with enterprise wide unique DNs though unless connected to a global X.500 directory.
These fields can be present in a DN:
* C : Country, Two letter country code as defined in ISO 3166.
* DC : Domain Component, modern attribute commonly used in LDAP directories, ex. CN=Tomas Gustavsson, DC=BigCorp, DC=com.
* ST : State of Province name. Not commonly used.
* L : Locality, e.g. Stockholm. Not commonly used for people, people move around alot, perhaps for routers etc.
* O : Organization name, e.g. PrimeKey Solutions AB.
* OU : Organizational Unit, e.g. Engineering.
* T : Title, not commonly used.
* Surname : Last name, e.g. Gustavsson.
* Givenname (gn) : First name, e.g. Tomas
* Initials : Initials, not commonly used.
* Serialnumber (sn) : Serialnumber of routers etc, could also be other registration number for people.
* CN : Common Name, e.g. Tomas Gustavsson
* UID : Unique id, commonly used for computer account name, e.g. tomas.
* Emailaddress : Should not be used, use alternative name for email address.
* UnstructuredName : ip-address of routers.
* UnstructuredAddress: DNS name of routers.
* PostalCode: The users postal code.
* Business Category: Describes the kinds of business performed by an organization.
Encoding of DN fields is a small science in it self, at least for the DN components that use the asn.1 DirectoryString. By default the behaviour in EJBCA is:
PrintableString is used for some fields that require it according to the standard. Regular values are encoed as UTF8String if the field value will decode to that, and finally BMPStrings if 16 bit characters are required.
There is an option in the CA configuration (Edit Certificate Authorities) called 'Use PrintableString encoding in DN'. When this option is checked, PrintableString will be used for those components where this is a choice (ASN.1 DirectoryString).
This option also affects SubjectDirectoryAttributes (placeOfBirth is a DirectoryString), and Certificate Policy User Notice Text.
See RFC5280 for encoding requirements.
Subject Alternative Names
Subject Alternative Names are stored as a standard X.509 certificate extension and ius used for address and name types that should not be present in DNs. There are a number of standard alternative names, see RFC 3280 for details. Below are the altenrative names supported by EJBCA.
- rfc822name : Email address, e.g. gro.niamodemos|nosrep#gro.niamodemos|nosrep.
- dNSName : DNS name, e.g. www.somedomain.org.
- uniformResourceIdentifier (uri) : URI, e.g. http://www.somedomain.org/.
- iPAddress : ip address of a server, e.g. 10.1.1.24.
- directoryName : Distinguished name like DN fields.
- upn : Microsoft domain name used for smart card logon, e.g. USER@SOMEDOMAIN.
- guid : Microsoft domain controller GUID, must be hex encoded guid string.
Edit CAs
When adding or editing CAs there are many fields that you can fill in.
Certificate profiles
Certificate profiles defines the (technical) contents of a certificate according to X.509 standard and RFCs. In the certificate profles you configure certificate extensions.
Information about fields in Certificate Profiles can be found here:
CertificateProfiles
End entity profiles
End entity profiles defines the fields that must, or can, be registered for specific types of users. It is here you define which DN fields (CN, O, OU, etc) that should be present for a type of user.
Information about fields in End Entity Profiles can be found here:
EndEntityProfiles
Publishers
see: Publishers
Hard token profiles
Hard token profiles defines the (technical) contents of a hard token. To issue hard tokens with EJBCA this feature must be enabled in system configuration. When this is done, EJBCA can help in issuing hard tokens with storing PIN codes etc.
Information about fields in Hard Token Profiles can be found here:
HardTokenProfiles
Common mistakes when configuring adminstrative priviledges
- When issuing administrators, remember that the administrator flag must be set for the user. This servers as an extra backup against missconfiguration and is set in the end entity profiles.
- When adding a administrator group remember that the CA you connect to the group must issue all the certificates of all the administrators that belong to the group.
- If you create a new rootCA issuing administrator certificates that is not signed by the AdminCA generated with the install script. Remember that you must add the new CA certificate to the JAVA_HOME/jre/lib/security/cacerts file and restart the application server.
- After editing the access rules it takes up to one minute for them to take effekc. So if you are experience problems with not accessing the right profiles/users/CAs directly after editing priviledges, wait one minute and restart the browser session.
Advanced Access Rules
see: AdvancedAccessRules
High Availabilty with the Health Check Servlet
see: HealthCheckServlet
Log signing
see: LogSigning