Test EJBCA 3.x should pass before a release

• Install EJBCA from scratch on another machine than the developers, preferably by someone other than the developer
• Upgrade EJBCA from an older version to the one about to be released

To be able to run all system tests, EJBCA_HOME/conf/ejbca.properties: ejbca.productionmode=false must be set.

Automated tests

Test: The following test should run on all supported environments:

ant test:run
ant test:runocsp
ant test:runweb
ant test:externalra-scep
ant test:externalra -Dexternalra.test.jdbcjar=$JBOSS_HOME/server/default/lib/mysql-connector-java-5.1.6.jar

Test of browser enrollment

This test requires a CA called TestCA with "CN=TestCAv1,O=TestOrg". All of the tests should be performed with certificates stored in the browser as well as on all supported cards with all supported CSPs.

Install CA cert in Firefox

Test: In the AdminGUI create a new end user, user generated key store. Go to public enrollment page enter username and password. Click on the link "Certificate Chain" to install the CA certificate. Check all trust-boxes.
Expected: Verify in Edit → Preferences → Advanced → Encryption → View Certificates → Authorities that the certificate is stored.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _
Browser version used in test: _ _ _

Enroll using Firefox

Test: Enroll for a new certificate.
Expected: Verify in Edit → Preferences → Advanced → Encryption → View Certificates → Your Certificates that the certificate is stored. Double click the certificate and check that it is verified at least for the purposes SSL Client cert, Email signer and Email Recipient.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _
Browser version used in test: _ _ _

Install CA cert in IE

Test: In the AdminGUI create a new end user, user generated key store. Go to public enrollment page enter username and password. Click on the link to install CA certificate. Select 'Open'. In the next window click 'Install certificate' and do next → next → finish..
Expected: Verify in Tools → Internet Options → Content → Certificates → Root Certificate that the certificate is stored.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _
Browser version used in test: _ _ _

Enroll using IE

Test: Enroll for a new certificate.
Expected: Verify in Tools → Internet Options → Content → Certificates → Personal that the certificate is stored. Double click and verify that the certificate is considered valid by IE.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _
Browser version used in test: _ _ _

Create a SubCA and enroll with Firefox

Test: Create a SubCA to TestCA, called TestSubCA with "CN=TestSubCAv1,O=TestOrg". Remove all certificate, both personal and CA-certificate installed earlier from Firefox and do the same test, but with the SubCA.
Expected: Verify in Edit → Preferences → Advanced → Encryption → View Certificates → Your Certificatesthat the certificate is stored. Double click the certificate and check that it is verified at least for the purposes SSL Client cert, Email signer and Email Recipient.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _
Browser version used in test: _ _ _

Create a SubCA and enroll with IE

Test: Using TestSubCA. Remove all certificate, both personal and CA-certificate installed earlier from IE and do the same test, but using the SubCA.
Expected: Verify in Tools → Internet Options → Content → Certificates → Personal that the certificate is stored. Double click and verify that the certificate is considered valid by IE.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _
Browser version used in test: _ _ _

Test of Certificate Revocation Lists

CRLs are tested as a part of the automated tests and this section describes complementary tests. This test requires a CA called TestCA with "CN=TestCAv1,O=TestOrg" and the initial AdminCA1.

Generate CRL for specified CA with CLI

Test: Run

bin/ejbca.sh ca createcrl TestCA

Generate CRL for all CAs with CLI

Test: Run

bin/ejbca.sh ca createcrl

Test: Wait until TestCAs CRL period is up and run

bin/ejbca.sh ca createcrl

Verify CRL with OpenSSL

Test: Download a CRL (with some revoked certs) from the publicweb and look at it with OpenSSL

openssl crl -text ...

Deploy the JBoss service for CRL generation

Removed in EJBCA 3.6. Ignore this test unless the release is for an earlier version.
Test: Run

ant deploywithjbossservices

Verify the JBoss service for CRL generation

Removed in EJBCA 3.6. Ignore this test unless the release is for an earlier version.
Test: Wait until a CAs CRL period expires
Expected: 10 minutes before the old CRL expires a new one should be generated automatically.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Verify the Jboss service for CRL with HSM CA

Removed in EJBCA 3.6. Ignore this test unless the release is for an earlier version.
Test: Create a CA using an HSM. Make the CA on-line, and wait until the CRL period expires.
Expected: 10 minutes before the old CRL expires a new one should be generated automatically.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Test: Make the CA off-line and have a few soft token Cas that also needs to generate CRLs.
Expected: The CRL generation for the HSM CA should fail, but the CRLs for the other CAs should be generated.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

CRLs in Mozilla

Test: Download a CRL to Mozilla from the Public web and enable the CRL check and automatic update in Mozilla. Verify a certificate first that is not revoked. Revoke the certificate and wait until the CRL expires.
Expected: Fist the certificate should verify fine, after revocation and a new CRL generation the new CRL should be downloaded to Mozilla and the certificate should not verify fine ("Could net verify for unknown reasons.").
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Test of External CAs

This section will test CAs that are signed by an external CA, and CAs signing other external CAs. This requires two completely separate EJBCA installations with different databases running, instance A and instance B. Instance A should have a CA called RootCA installed.

Create a new CA signed by external CA

Test: On instance B create a CA, called TestCA, signed by “External CA”
Expected: A certificate request should be created
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Sign an external CA

Test: On instance A, create a new CA and process the certificate request created in the previous test.
Expected: A certificate should be created for TestCA. TestCA should be visible on instance A.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Import certificate issued by external CA

Test: On instance B, receive the certificate for TestCA
Expected: TestCA should be operational and visible on instance B. Basic functions should let you view both TestCAs certificate and RootCAs certificate..
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Test of International character handling

This test requires EJBCA installed both using the default database (Hypersonic) and MySQL 5.x and each having a CA called TestCA.

Generate PEM user with CLI and Hypersonic

Test: On the Hypersonic CA: Generate a new user using the CLI

bin/ejbca.sh ra adduser testi18npem foo123 "CN=åäöÅÄÖ, O=åäöOrg, C=SE" null AdminCA1 null 1 PEM
bin/ejbca.sh ra setclearpwd testi18npem foo123
bin/ejbca.sh batch

openssl x509 -in p12/pem/åäöÅÄÖ.pem -text

openssl asn1parse -in p12/pem/åäöÅÄÖ.pem

Generate user generated user with CLI and Hypersonic for FireFox

Test: On the Hypersonic CA: Add a new used using the CLI

bin/ejbca.sh ra adduser testi18nug foo123 "CN=åäöÅÄÖ, O=åäöOrg, C=SE" null AdminCA1 null 1 USERGENERATED

Generate user generated user with CLI and Hypersonic for IE

Test: On the Hypersonic CA: Add a new used using the CLI

bin/ejbca.sh ra adduser testi18nug foo123 "CN=åäöÅÄÖ, O=åäöOrg, C=SE" null AdminCA1 null 1 USERGENERATED

Generate PEM user with AdminGUI and Hypersonic

Test: Run on the Hypersonic CA. Add a new used using the AdminGUI. The DN should be “CN=åäöÅÄÖ, O=åäöOrg, C=SE”. Keystore type PEM. Check 'batch' and batch generate.
Expected: Verify in the certificate using

openssl x509 -in <cert.pem> -text

openssl asn1parse -in <cert.pem>

Generate user generated user with AdminGUI and Hypersonic for FireFox

Test: On the Hypersonic CA: Add a new used using the AdminGUI. The DN should be “CN=åäöÅÄÖ, O=åäöOrg, C=SE”. Keystore type USERGENERATED. Apply using Firefox/Mozilla.
Expected: Look at the certificate in FireFox and verify the name åäöÅÄÖ.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _
Browser version used in test: _ _ _

Generate user generated user with AdminGUI and Hypersonic for IE

Test: On the Hypersonic CA: Add a new used using the AdminGUI . The DN should be “CN=åäöÅÄÖ, O=åäöOrg, C=SE”. Keystore type USERGENERATED. Apply using IE.
Expected: Look at the certificate in IE and verify the name åäöÅÄÖ.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _
Browser version used in test: _ _ _

Test international characters with MySQL

Test: Run all the previous internationalisation tests on the MySQL CA.
Expected: Same as with Hypersonic.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

E-mail Notifications

This test requires a CA called TestCA and Mail configured in JBoss as described the EJBCA User Guide.

Create profile using mail notifications

Test: In the AdminGUI create a new end entity profile called NotificationProfile. Select 'use' at Send Notification. Set your (valid) email address as Notification Sender.
STATUS_NEW, STATUS_INITIALIZED, STATUS_KEYRECOVERY is fine. Use a message like:

${user.USERNAME} = The users username
${user.PASSWORD} = The users password
${user.CN} = The common name of the user.
${user.TIMECREATED} = The time the user was created
${user.TIMEMODIFIED} = The time the user was modified

Create end entity

Test: Add a new end entity using the Notification Profile, give username not1. Set a valid email address that you can check. Press Add End Entity.
Expected: A notification message should arrive to the given email address.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Change end entity to generated

Test: Go in under List End Entities and find end entity with username not1. Click Edit End Entity, flip status to Generated and save.
Expected: No notification is sent. If you press Edit End Entity again, status is Generated.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Change end entity to new

Test: Go in under List End Entities and find end entity with username not1. Click Edit End Entity, give a new password, flip status to New and save.
Expected: A notification message should arrive to the given email address.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Use auto-generated passwords

Test: Edit the End Entity Profile again. Check auto-generated under Password and save.
Expected: The last password field is disabled (greyed out) and the Auto-generated check-box is checked.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Create and change end entity

Test: Run tests "Create end entity", "Change end entity to generated" and "Change end entity to new" again. In the last test the Regenerate New Password check-box has to be checked instead of giving a new password.
Expected: See the result from those tests.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Use clear text passwords

Test: Edit the End Entity Profile again. Click Use for Batch Generation and save.
Expected: The use checkbox is checked.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Create and change end entity

Test: Run tests "Create end entity", "Change end entity to generated" and "Change end entity to new" again.
Expected: See the result from those tests.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Require notification

Test: Edit the End Entity Profile again. Click Default and Require for Send Notification.
Expected: The Default and Required check-boxes are checked.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Create and change end entity

Test: Run tests "Create end entity", "Change end entity to generated" and "Change end entity to new" again. Now you can not uncheck the Send Notification check-box in the Edit End Entity window. (????)
Expected: See the result from those tests.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

OCSP

This tests requires a TestCA, and for some tests this CA has to use PrimeCardHSM. Automatic JUnit tests are available:

ant test:runweb

bin/ejbca.sh ra adduser ocspTest foo123 "CN=ocspTest" null AdminCA1 null 1 PEM
bin/ejbca.sh ra setclearpwd ocspTest foo123
bin/ejbca.sh batch
bin/ejbca.sh ra revokeuser ocspTest 9
bin/ejbca.sh ra setuserstatus ocspTest 10
bin/ejbca.sh ra setclearpwd ocspTest foo123
bin/ejbca.sh batch
ant test:runocsp

Test EJBCA OCSP using OpenSSL

Test: Batch generate a user with PEM files and request the user status

bin/ejbca.sh ra adduser ocsp1 foo123 "CN=ocsp1" null TestCA null 1 PEM
bin/ejbca.sh ra setclearpwd ocsp1 foo123
bin/ejbca.sh batch
openssl ocsp -issuer p12/pem/ocsp1-CA.pem -CAfile p12/pem/ocsp1-CA.pem -cert p12/pem/ocsp1.pem -req_text -url http://localhost:8080/ejbca/publicweb/status/ocsp

Test: Revoke the certificate for ocsp1. Generate the same request as in the previous test with OpenSSL:

bin/ejbca.sh ra revokeuser ocsp1 0
openssl ocsp -issuer p12/pem/ocsp1-CA.pem -CAfile p12/pem/ocsp1-CA.pem -cert p12/pem/ocsp1.pem -req_text -url http://localhost:8080/ejbca/publicweb/status/ocsp

OCSP Response signed by CA in Firefox

Test: Have OCSP configured as default in ocsp.properties (i.e. restore all values). Create a new certificate profile with an OCSP URL and generate the new PKCS#12 user 'ocsp2' using this profile. Go to Edit → Preferences → Advanced → Encryption → Validators and make sure certificates are validated if they contain an OCSP URL. Import ocsp2.p12 and view the certificate.
Expected: This should trigger an OCSP request in the JBoss log and the cert will be shown as ok.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _
Browser version used in test: _ _ _

Test: Revoked the certificate for ocsp2. View the certificate once more in Firefox.
Expected: Firefox should query the OCSP server again and it should show "Could not verify this certificate for unknown reasons." (You might have to restart Firefox.)
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _
Browser version used in test: _ _ _

OCSP Response signed by untrusted responder certificate in Firefox

Test: Generate a new certificate for ocsp2 and import that in Firefox (delete the old one). Configure the OCSP service to use External responder in ejbca.properties and re-deploying EJBCA. Double click on ocsp2's certificate in Firefox.
Expected: Firefox should query the OCSP server say that there is something wrong with the response, it can not verify the response.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _
Browser version used in test: _ _ _

OCSP Response signed by trusted responder certificate in Firefox

Test: Use Firefox to go to the Public web of EJBCA and import TestCAs OCSP-responder certificate as a trusted certificate. Double click on ocsp2's certificate in Firefox.
Expected: Firefox should query the OCSP server say that everything is fine.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _
Browser version used in test: _ _ _

Configure an external OCSP responder

Test: Set up an external OCSP responder with a publisher from EJBCA to the external OCSP responders database. This is described in OCSP Install docs and can take a little time. Re-run last two tests (Firefox with responder certificate) against the external OCSP service.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Test: Use only a single P12 (ocspSigner) in the external OCSP responder issued by AdminCA1. Create a user from TestCA and make sure both the CA and user certificate is available on the OCSP responder.

openssl ocsp -issuer p12/pem/ocsp5-CA.pem -CAfile p12/pem/ocsp5-CA.pem -cert p12/pem/ocsp5.pem -req_text -url http://ocsp:8080/ejbca/publicweb/status/ocsp -VAfile ocspSigner.pem

OCSP Service locator URI

Test: Use the integrated OCSP responder signed directly by the CA again. Configure the certificate profile to use an OCSP service locator. Issue a new PKCS12 certificate for ocsp3. Configure Firefox to only verify using OCSP if there is an OCSP service locator. Revoke ocsp2. In Firefox double click on ocsp2.
Expected: The OCSP responder should not be queried and ocsp2's revoked certificate should be reported as valid.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _
Browser version used in test: _ _ _

Test: Double click on ocsp3.
Expected: The OCSP responder should be queried and ocsp3's revoked certificate should be reported as valid.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _
Browser version used in test: _ _ _

Test: Revoke ocsp3. Double click on ocsp3.
Expected: The OCSP responder should be queried and ocsp3's revoked certificate should be reported as revoked.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _
Browser version used in test: _

Internal OCSP using HSM

Test: Create a new CA using an HSM, HardCA. Configure OCSP as default, i.e. signed by CA. Create a new user and re-run the simple tests (Firefox with OCSP signed by CA) against the user on HardCA.
Expected: Everything should work just like for a Soft token CA.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _
Browser version used in test: _ _ _

External OCSP using HSM

Test: Set up the external OCSP responder using an HSM according to the OCSP Install documents. Verify a response using OpenSSL.
Expected: Everything should work.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Publishers

These tests require a CA called TestCA and OpenLDAP 2.2.18 or similar installed and configured. Admin user “cn=admin,dc=company,dc=com”. Top node “dc=company, dc=com” added (see HOWTO-LDAP.txt).

Create publisher for OpenLDAP

Test: In the admin-GUI create a new publisher for the OpenLDAP server set up. Choose 'CN' in LDAP location fields. BaseDN is 'dc=bigcorp,dc=com'. For example, if slapd.conf contains:

suffix          "dc=bigcorp,dc=com”
rootdn          "cn=Admin,dc=bigcorp,dc=com"

Publish CA cert

Test: In the CA configuration add the new publisher as 'CRL Publishers'. This CA is used for all other tests below. Republish CA certificate.
Expected: The CA certificate and the current CRL should be published in LDAP (see User's Guide how to check the ldap database).

ldapsearch -x -b 'dc=bigcorp,dc=com' '(objectclass=*)'

Publish CA CRL

Test: Create a new CRL under 'Basic Functions'.
Expected: The new CRL should be published in LDAP under the same object as before, replacing the old CRL in both attributes certificateRevocationList;binary and authorityRevocationList;binary.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Create profiles

Test: Create a certificate profile that will be used by a CA when generating new users use your new Publisher, use the ENDUSER profile as template. Select the new publisher in the certificate profile. Create an entity profile using the new certificate profile, use DN fields C,O,OU,L,title,CN. Email as altName. Use Batch. Use the new certificate profile as default certificate profile. The new CA as default CA. PEM file as default token.
Expected: certificate profile and entity profile exists.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Create new user no email

Test: Add a new user with the new profile. Batch, no email address, CN, O and C. Use a real common name like 'Foo Foosson'. Batch generate the user.
Expected: The user and his certificate is published in LDAP, no email attribute is present, but CN, surname etc is present. The entry should look like:

# Foo Foo, bigcorp.com
dn: cn=Foo Foosson,dc=bigcorp,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Foo Foosson
sn: Foosson
givenName: Foo
o: QWO
userCertificate;binary:: <base64 encoded cert>

Create new user with email as altName

Test: Add a new user like above but with a simple CN like only 'Barsson” and a title and with an email address as altName. Batch generate.
Expected: The user and his certificate is published in LDAP, an email attribute is present, CN, surname etc is also present.

# Barsson, bigcorp.com
dn: cn=Barsson,dc=bigcorp,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Barsson
sn: Barsson
o: BarO
title: BarT
mail: bar@bar.com
userCertificate;binary:: <base64 encoded cert>

Modify existing user with email

Test: Modify the first existing user and add an email address as altName and an L. Give new password set status to new and regenerate with batch.
Expected: The user is modified in LDAP, the email and L attributes are added. The new certificate is published in LDAP. Otherwise the LDAP entry looks the same:

# Foo Foosson, bigcorp.com
dn: cn=Foo Foosson,dc=bigcorp,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: Foo Foosson
l: FooL
sn: Foosson
givenName: Foo
o: QWO
mail: foo@foo.com
userCertificate;binary::<base64 encoded cert>

Create new user with email in DN

Test: Add a new user with an email address in the DN. You have to change the entity profile to add 'email in DN'. Do not use any altName now. Batch generate.
Expected: The user and his certificate is published in LDAP, an email attribute is present, CN, surname etc is also present.

# qwe, bigcorp.com
dn: cn=qwe,dc=bigcorp,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: qwe
sn: qwe
o: qweO
mail: qwe3@qwe.com
userCertificate;binary:: <base64 encoded cert>

Create user for another CA

Test: Create a user with another CA, using the default entity and certificate profiles. Use batch, and batch generate the user.
Expected: Nothing should be added to LDAP for this user.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Use SSL connection to OpenLDAP

Test: Follow the chapter 'Configure SSL' in HOWTO-LDAP.txt. Edit the publisher and check the checkbox for using SSL. Regenerate the last user created above.
Expected: 'Save and test connection' is succesful when editing the publisher. The certificate for the re-generated user is replaced in LDAP with the new ly generated cert.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Revoke user

Test: Select a user that has been published in LDAP from the above tests. Revoke the users certificates.
Expected: In the LDAP directory the users userCertificate field should be empty, the certificate was removed when the revocation was done.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Create LDAP Search Publisher and publish a cert to existing user

Test: Create a user with the normal publisher. Call the user 'ldap1' or similar. Have DN like “cn=ldap1, uid=ldap2, o=foo,c=se” (uid must not be the same as the username). The user should be created in LDAP with a certificate. Now create a new publisher using the “LDAP.Search Publisher”. Use the same parameters for BaseDN etc as in the regular publisher. For Search settings, set the same as BaseDN as SearchBase. As filiter enter “uid=$USERNAME”. Create a new certificate profile and end entity profile using the new publisher. Create a new user in EJBCA with the new profile/publisher, the users username should be ldap2 (same as uid in the earlier user). Generate a certificate for the user ldap2.
Expected: In the LDAP directory the user ldap1 should have the certificate updated when ldap2 gets a new certificate. This is because when ldap2 is generated EJBCA searches for uid=ldap2 in LDAP and finds the entry for cn=ldap1…
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Create a new user with LDAP search publisher

Test: Perform test "Create new user with email as altName" but using the LDAP Search publisher, i.e. using he new entity profile created above. Use a new user with uniquie DN, username and uid (uid same as username). Generate the user.
Expected: The user should be created in LDAP exactly the same way.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Create intermediate nodes

Test: Edit the normal LDAP publisher and also select OU as LDAP location fields. Create a new user with unique DN (CN=Unigue4711, OU=FooOU), username and uid (uid same as username). Generate the user.
Expected 1: The user will be generated bu the certificate will not be published to LDAP.

2007-10-25 09:03:28,047 ERROR [org.ejbca.core.model.ca.publisher.LdapPublisher] LDAP ERROR: Error storing certificate (userCertificate;binary) in LDAP (top;person;organizationalPerson;inetOrgPerson) for DN (CN=Bar Barsson,OU=FooOU,dc=bigcorp,dc=com).
LDAPException: No Such Object (32) No Such Object
LDAPException: Matched DN: dc=bigcorp,dc=com

Expected 2: The user will be generated and and his certificate is published in LDAP.

# Bar Barsson, FooOU, bigcorp.com
dn: cn=Barsson,ou=FooOU,dc=bigcorp,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
givenName: Bar
cn: Bar Barsson
sn: Barsson
o: Foo
ou: FooOU
userCertificate;binary:: <base64 encoded cert>

Create publisher for AD

todo

Log Signing

This test requires a CA called TestCA.

Enable log signing with clear text password

Test: Create protect.properties according to HOWTO-logsigning.txt, use clear text password.Re-deploy EJBCA and enter the admin-GUI.
Expected: Everything should work as before, and a few lines should be written to the TableProtectData table in the database..
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Verify logs

Test: Go into the admin-GUI and check the log.
Expected: The log lines should say verified for the last lines, earlier lines should say that verify failed, because there are no protection entrys for them.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Enable log signing with encrypted password

Test: Create protect.properties according to HOWTO-logsigning.txt, use encrypted password. Use the same password as before. Re-deploy EJBCA and enter the admin-GUI.
Expected: Everything should work as before, and a few lines should be written to the TableProtectData table in the database..
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Verify logs

Test: Go into the admin-GUI and check the log.
Expected: The log lines should say verified for the last lines, and the lines before logged with clear text password, earlier lines should say that verify failed, because there are no protection entrys for them.
Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Administrative Delegation

The main focus of this test specification is target at the administrative delegation options. To test them a hypothetical environment will be setup as follows:
One instance of EJBCA maintained by the company ”Walter”, acting as a CASP (Certificate Authority Service Provider). Walter have two customers, ”Donny Inc” a smaller organisation with one department in need of a RA, and a little bigger company ”Dude Inc” with two departments in need of separate RAs ”Dude Department West” and ”Dude Department East”.

Role definitions

To this environment there is a few administrators with different roles in the system:

• One Super administrator working at Walter. He should be able to create and edit CA:s for new customers.
• One CA Administrator working at Dude Inc. He should setup Certificate Profiles and RA Profiles, he should also be able to define new administrators working at Dude Inc.
• Two RA Administrators able to create/edit/revoke end entities for each of the company's two departments.
• One Supervisor able to overlook all the ”Dude Inc” created end entities and to view the log concerning the company.
• One CA Administrator working at Donny Inc. He should be able to setup Certificate Profiles and RA Profiles, he should also be able to define a new administrator working at Donny Inc.
• One RA Administrator, able to create/edit/revoke end entities for the company's department.

Super Administrator at “Walter”

The super administrator should be able to:

• Traverse thru all available web – pages.
• Able to create one CA Certificate profile with it's CRL dist point defined. Set to Any CA.
• Able to create one End Entity Certificate profile “Walter Cert”, with it's CRL dist point defined. Set to Any CA.
• Able to create Three CA:s
  • one “CN=Walter CA1, O=Walter, C=SE”, Self-signed 4096-bit.
  • one “CN=Dude Inc CA1, O=Dude Inc, C=SE”, Signed by “Walter CA1” 2048 bit
  • one “CN=Donny Inc CA1, O=Donny Inc, C=SE”, Signed by “Walter CA1” 2048 bit, “RFC822NAME=es.ynnod|ac#es.ynnod|ac”
• Able to create two CA administrators with access rights each CA.
• Able to view all the systems created users.

The super administrator should not be able to:

• There is nothing the super administrator shouldn't be able to do.

Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

CA Administrator for “Dude Inc”

The CA administrator should be able to:

• Create one End Entity Certificate profile “Dude Cert”, with “Walter Cert” as template.
• Create Two End Entity Profiles
  • one “Dude West” with OU set to “Dude Department West” and “Dude Cert” as certificate profile.
  • one “Dude East” with OU set to “Dude Department East” and “Dude Cert” as certificate profile, used for batch generation
• Create two RA Administrators with access rights to their corresponding end entity profile.
• Create one Supervisor with view rights to all the CA's created end entities and log.
• Configure log configuration of “Dude Inc CA1”.

The CA administrator should not be able to:

• See any end entities, profiles or CA info or log entires belonging to ”Donny Inc CA1”.
• Edit the “Walter Cert”

Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

RA Administrator for “Dude West Department”

The RA administrator should be able to:

• Create four End entities all using “Dude West” and “Dude Cert” profiles.
• One “BROWSERTEST” with browser generated keystore
• One “P12TEST” with P12 keystore fetched in public web.
• One “JKSTEST” with JKS keystore fetched in public web.
• One “PEMTEST” with PEM keystore fetched in public web.
• Able to view/edit/view certificates/view history and revoke the specified users.

The RA administrator should not be able to:

• See any end entities, profiles or CA info or log entires belonging to ”Donny Inc CA1” or “Dude East Department”

Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

RA Administrator for “Dude East Department”

The RA administrator should be able to:

• Create three End entities all using “Dude East” and “Dude Cert” profiles.
• One “P12TEST” with P12 keystore generated by a batchjob.
• One “JKSTEST” with JKS keystore generated by a batchjob.
• One “PEMTEST” with PEM keystore generated by a batchjob.
• Able to view/edit/view certificates/view history and revoke the specified users.

The RA administrator should not be able to:

• See any end entities, profiles or CA info or log entires belonging to ”Donny Inc CA1” or “Dude West Department”

Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Supervisor for “Dude Inc”

The Supervisor should be able to:

• Able to view end entities, certificates and history of all Dude Inc's end entities.
• Able to view the log data generated by “Dude Inc CA1”.

The RA administrator should not be able to:

• Edit anything in any way.
• See log data generated by another CA.

Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

CA Administrator for “Donny Inc”

The CA administrator should be able to:

• Create one End Entity Certificate profile “Donny Cert”, with “Walter Cert” as template.
• Create one End Entity Profiles
  • one “Donny Dep” with OU set to “Donny Department” and “Donny Cert” as certificate profile.
• Create one RA Administrators with access rights to the “Donny Dep” end entity profile.
• Configure log configuration of “Donny Inc CA1”.

The CA administrator should not be able to:

• To see any end entities, profiles or CA info or log entires belonging to ”Dude Inc CA1”.
• Not able to edit the “Walter Cert”

Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

RA Administrator for “Donny Department”

The RA administrator should be able to:

• Create four End entities all using “Donny Dep” and “Donny Cert” profiles.
  • One “DONNYTEST” with browser generated keystore
• Able to view/edit/view certificates/view history and revoke the specified user.

The RA administrator should not be able to:

• See any end entities, profiles or CA info or log entires belonging to ”Donny Inc CA1”.

Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

External RA API

1. RA and CAService keystores generated by a Root CA.
2. RA and CAService keystores generated by a SubCA.
3. Unsigned messages isn't accepted if signing is set as required.
4. Unencrypted messages isn't accepted if encryption is set as required.
5. If RA certificate is revoked the wont any more messages be accepted.
6. If CA certificates (Either Root or Sub) is revoked wont the any more message be accepted
7. Check that if all certificates are revoked, then is also the user status set to 'Revoked'.
8. Authorization tests of signed messages that should be denied:
   1. The administrator haven't access to the CA specified in request.
   2. The administrator haven't access to the End Entity Profile specified in request.
   3. The administrator haven't create rights
   4. The administrator haven't got edit rights
   5. The administrator haven't got key recovery rights

Result (U=Untested, O=OK, F=Failed, X=Test is obsolete): _ _ _

Sign-off

The results from the tests above are correct to the best of my knowledge.