EJBCA support, development and maintenance
by
- Installation
- Building and configuring EJBCA
- Building and configuring the Responder
- Dynamic reconfiguration
- Key updating
- Automatic re-keying
- No password in memory
- Several responders using same HSM
- Error handling
- Running several responders
- Adding additional responders in a live environment
- Audit and Account Logging
- Setting up the Unid-Fnr OCSP extension
- Configuring the Unid lookup server
- Configuring TLS on the Unid lookup server
- Security of the lookup server
- Using database integrity protection
- OCSP GET
- Responses with longer validity and caching
Installation
Installing the external OCSP responder together with EJBCA requires configuration on the CA and installation of the external OCSP responder.
If you are not using the responder with EJBCA you can skip the section about building and configuring EJBCA.
Building and configuring EJBCA
EJBCA should be configured as for any other installation but you must also set all preferences (ocsp-database.*) of the responder database in conf/ocsp.properties. The responder database is the master database of all the responders, and it is there that EJBCA will publish certificates when they are issued or revoked.
After this configuration EJBCA is built and deployed as usual with the command 'ant deploy', as described in the EJBCA installation guide.
The deploy command sets up a datasource java:/OcspDS in JBoss, if you use another application server you must set up this datasource manually. It should be a datasource that is not involved in transactions (a no-tx-datasource in JBoss), and is should have autocommit (should be default in JBoss).
When EJBCA has been started you have to add a new publisher. As a superadministrator you add this publisher on the "Edit Publishers" page in the admin GUI. Use publisher type "External OCSP Publisher".
External OCSP Settings:
- 'Data Source' - is the database of the external OCSP where this publisher will publish certificates. Use java:/OcspDS if ocsp-datasource.jndi-name=OcspDS.
- 'Store certificate on responder' - stores the complete certificate on the responder. If this is unchecked only the information needed to answer OCSP requests are stored, but not the certificate itself. There are good reasons not to publish the whole certificate. It is large, thus making it a bit of heavy insert and it may contain sensitive information. On the other hand some OCSP Extension plug-ins may not work without the certificate. A regular OCSP responder works fine without the certificate.
All certificate profiles for certificates that should be available to the OCSP responder should have a reference to this publisher. To configure this you must be a superadministrator.
When all settings above have been done then all created certificates issued with a certificate profile that has the ExternalOCSPPublisher as publisher should be published in the responder database as well as in the EJBCA database. When a certificate is revoked it will be revoked in the responder database as well. If the publishing is not working it is important to notice this and synchronize the databases again, see 'Error publishing to OCSP database' below.
Building and configuring the Responder
The responder is configured using the same configuration files as EJBCA.
Only the preferences ocsp.*, httpsserver.*, datasource.* and database.* are relevant to the responder but you may keep conf/*.properties
from the EJBCA setup since definitions of other properties does no harm.
Please read description of the configuration properties in conf/ocsp.properties.sample, conf/database.properties.sample and perhaps conf/web.properties.sample (if ssl or different ports should be configured).
All options for the OCSP responders OCSP behavior is set in conf/ocsp.properties. All options are documented in this file.
The ocsp.keys.* preferences (that has no meaning for EJBCA) has also to be configured.
ocsp.usecasigningcert should be set to false.
If card keys (see below) should be used then the property 'ocspHardTokenClasses' must be set to the corresponding directory of PrimeCard.
The responder is then built and deployed with:
ant ocsp-deploy
on the external OCSP responder.
*** Responder database ***
The external OCSP responder database (that OcspDS in EJBCA and EjbcaDS in OCSP responder) points to only have to contain the CertificateData table. This table is created automatically by JBoss when it starts on the external OCSP responder.
The database connection settings on the external OCSP responder is configured and deployed in JBoss in the file JBOSS_HOME/server/default/deploy/ejbca-ds.xml.
*** Responder signing keys ***
The keys used to sign the OCSP response could either be stored on as a PKCS#12 file in the file system of the host,
on a smart card or on a PKCS#11 token. It should be one key for each CA, and the each CA the responder answers for an OCSP signing certificate must be issued.
The certificate profile could be the same for both soft, smart card and PKCS#11 keys.
To issue OCSP signer certificate from EJBCA you define a new certificate profile and use 'OCSPSIGNER (FIXED)' as template (use selected as template).
This certificate profile is like a normal end entity profile but with the following key usages:
- Key Usage: Digital Signature - Extended Key Usage: OCSPSigner
Configure the newly created certificate profile to use the OCSP publisher defined above. You also need to create a new End Entity Profile to use the new Certificate Profile.
You should then create a user for each CA using this certificate profile. Use the token type "p12" or "jks" for soft keys and "user generated" for pkcs#11 and card keys.
*** Soft keystores ***
When a soft key has been created it should be stored in the directory defined by the ocsp.keys.dir property of conf/ejbca.properties. The password for each key must be the same and should be equal to the ocsp.keys.keyPassword property of conf/ejbca.properties.
Soft OCSP keystores are most easily created by adding a user to EJBCA and selecting the PKCS#12 keystores type. After this the OCSP keystore can be created by running the bin/ejbca.sh batch command on the EJBCA server, or by fetching the PKCS#12 keystore from the public enrollment pages of EJBCA.
*** PKCS#11 HSMs ***
A PKCS#11 key and certificate is created like this:
ejbcaClientToolBox.sh PKCS11HSMKeyTool generate ./sunpkcs11.cfg 2048 ocsp ejbcaClientToolBox.sh PKCS11HSMKeyTool certreq /opt/nfast/toolkits/pkcs11/libcknfast.so i1 ocsp
The certificate for the key is then fetched from the public enrollment page of EJBCA with the certificate request that was stored in the file ocsp.pem when the "certreq" command was executed. You then have to manually create a certificate chain file. The OCSP signer certificate should be first in this file and the root CA certificate should be last.
If the chain file is called chain.pem then the certificate chain is installed in the HSM like this:
ejbcaClientToolBox.sh PKCS11HSMKeyTool installcert /opt/nfast/toolkits/pkcs11/libcknfast.so i1 chain.pem
You must then define all ocsp.p11.* properties on the responder. Please read Generic PKCS#11 provider for information on the configuration file for the generate command. Do also try to find your HSM in Hardware Security Modules (HSM). Please note the only PKCS#11 HSMs are supported.
*** PrimeCardHSM ***
Smart card keys are created on the card with the "create CA Token on card" tool see the HOWTO-CATokenOnCard.txt of PrimeCard. Select the choice for one authentication code for all keys on the card. If you want several OCSP responders with same keys then you may create several card with same keys. But note that no backup card is needed. If a card is lost or broken then simply make another one with new keys and revoke the old signing certificates.
The certificates for the the keys are then fetched from the public enrollment page of EJBCA with the certificate request. There should be one certificate request for each key.
The command:
changePIN.sh createCertReqs
will create the requests, one for each key. Choose 'pem' format for the certificates and then just store these files in the 'ocsp.keys.dir' directory. The property 'ocsp.keys.cardPassword' should be set to the PIN of the card.
Re-start the application server for the external OCSP responder. When the application server is started it should just work.
Dynamic reconfiguration
By configuring the property 'allow.external-dynamic.configuration' in conf/ejbca.properties you can have the OCSP responder re-read some configuration values from files in the file system. The values ocsp.untilNextUpdate and ocsp.maxAge from ocsp.properties will be re-read if you put an ocsp.properties file in the directory /etc/ejbca/conf or in APPSRV_HOME/bin/conf (of you start your appserver from APPSRV_HOME/bin).
Key updating
The responder might be configured (in ocsp.properties) to scan for installed keys at regular intervals. The responder will use the keys detected at the latest scan.
Please not that keys in the PKCS#11 slot will not be updated if automatic re-keying is enabled.
Automatic re-keying
Re-keying is enabled by specifying a web-service URL and a "update time before the OCSP signer certificate expires time".
You got to generate a certificate for a user with permissions to create a user generated certificate for all OCSP signers. The entity for this user could be stored in a SW keystore or in the HSM. Please read the ocsp.properties.sample for further requirements and location of this entity.
To test the feature it is good to re-key frequently. This is achieved by setting "update time before the OCSP signer certificate expires time" close to validity length of the OCSP certificate. Example for 730 days (730*24*60-14)*60=63071160. This will force a re-keying every 4th minute (an EJBCA certificate is valid 10 minutes before it was issued).
When running on some application servers jar files of the application server has to be deleted.
In jboss-4.2.3.GA these files has to be deleted when running java6:
$APPSRV_HOME/server/default/lib/jboss-jaxrpc.jar $APPSRV_HOME/server/default/lib/jboss-jaxws-ext.jar $APPSRV_HOME/server/default/lib/jboss-jaxws.jar
For java5 one more files has to be deleted:
$APPSRV_HOME/server/default/lib/jboss-jaxrpc.jar $APPSRV_HOME/server/default/lib/jboss-jaxws-ext.jar $APPSRV_HOME/server/default/lib/jboss-jaxws.jar $APPSRV_HOME/server/default/lib/jboss-saaj.jar
For java5 you also got to add client WS jars since java5 got no WS support. These files should be added in $APPSRV_HOME/lib/endorsed if you are running jboss-4.2.3.GA. If you compile EJBCA ClientToolBox you got all needed files in the created 'clientToolBox-dist/endorsed' directory. Just copy or soft link them to the target.
No password in memory
With this feature enabled no password are kept in memory. If it is enabled you must not define any passwords in ocsp.properties.
Defining this feature makes it impossible to do "key updating".
Several responders using same HSM
If several responders should share the same HSM and rekeying should be enabled on all of them then each responder must use different keys. To be able to define this set of keys that should be used there is a property called 'ocsp.rekeying.listOfAliases' in the ocsp.properties file.
Error handling
If there is an error publishing to the OCSP database, the OCSP responder will be out of sync with the CA. It is very important to re-synchronize the databases in that case.
In case of failure to publish to the OCSP database the following error message will appear in the server.log:
EXTERNAL OCSP ERROR, publishing is not working
This will be followed by more details of the error.
The log must be monitored to discover such a fault and if such a fault is discovered an alarm should notify the operator that he has to fix whatever is wrong and then synchronise the OCSP database with the EJBCA database (see 'Synchronise the database of the responder').
Synchronise the database of the responder
At the beginning and after failure in publishing to the responder, the master database of the publishers must be synchronised with the CertificateData table of the database of EJBCA.
If there is a single certificate out of sync you can re-sync it by doing a 'Republish' from the admin-GUI.
The following procedure may be used to synchronise the database of EJBCA with the database of the responder:
1. Prevent any further issuing of new certificates and revocation of old certificates until the
synchronisation is finished. This might be done by simply blocking the port to the adminweb.
2. On the host of ejbca the following commands can be used to make the synchronisation:
Run on the OCSP responder machine (as root user in mysql):
mysqladmin drop ocsp_db; mysqladmin create ocsp_db;
This drops and re-creates the ocsp database to clean it. Replace ocsp_db with the database name of your database.
Run on the CA server:
mysqldump -u ejbca -p --compress ejbca_db CertificateData > CertificateData.dat mysqldump -u ejbca -p --compress ejbca_db TableProtectData > TableProtectData.dat cat CertificateData.dat | mysql -h ocspresponder ocsp_db cat TableProtectData.dat | mysql -h ocspresponder ocsp_db
Replace your the username ejbca with your username. ocspresponder is the external OCSP responder host.
3. Check that the publishing is working before allowing issuing and revoking.
Running several responders
Additional OCSP DataSources for OCSP responders have to be added manually. The easiest way to do this on JBoss is to clone the initially deployed OCSP DataSource JBOSS_HOME/server/default/deploy/ocsp-ds.xml to JBOSS_HOME/server/default/deploy/ocsp2-ds.xml and change
<jndi-name>OcspDS</jndi-name>
<connection-url>jdbc:mysql://ocsp1.domain.org:3306/ejbca</connection-url>
to
<jndi-name>Ocsp2DS</jndi-name>
<connection-url>jdbc:mysql://ocsp2.domain.org:3306/ejbca</connection-url>
and configure an additional publisher to use this new DataSource 'java:/Ocsp2DS'.
An alternative approach for MySQL users is to use the tools for database replication. Either you could replicate CertificateData from you master EJBCA database to slave-responders or you could publish to a master OCSP responders database that in turn is replicated to the other responders. How to do it is described in the mysql documentation. Depending on which which version you are using please read one of the followings: MySQL 5.0 Replication Howto MySQL 5.1 Replication Howto
Adding additional responders in a live environment
There is no automated way of pushing all the certificates that has been published to existing OCSP responders. To duplicate an existing "source" OCSP database to a "target" OCSP database:
- To create the tables in the target OCSP, start JBoss AS with OCSP deployed for the first time (and then stop the server before doing the next step).
- Add an additional DataSource for the target OCSP responder in EJBCA.
- Configure a new OCSPPublisher in EJCBA that uses the target OCSP DataSource. Chose to only publish to queue to accumulate all changes during the cloning.
- Wait one hour and check that there is nothing in the publisher-queue of the source OCSP that is older than one hour.
- Do a MySQL dump from the source database to the target database or use the ClientToolBox DBCOPY-command.
- When the copy operation has finished, configure a new Republisher Service for the target's OCSP Publisher.
- Make sure that the queue that built up during the copy operation is now published to the target OCSP.
- Run the monitoring tool (ClientToolBox OCSPMon) to verify that the new OCSP is in sync.
- Start the new OCSP node and add it to the pool of OCSPs in your load balancer.
Audit and Account Logging
There are three types of logs that can be generated by the OCSP responder.
1. The OCSP service logs using Log4j to the JBoss server.log. The JBoss server log is located in JBOSS_HOME/server/default/log/server.log and the logging is configured in JBOSS_HOME/server/default/conf/jboss-log4j.xml.
2. The OCSP transaction log can be used to log various information about ocsp-requests.
Transaction logging logs summary lines for all OCSP request/responses, which can be used for charging clients if you are running a commercial OCSP service.
To turn on transaction logs logs, copy ocsp.properties.sample to ocsp.properties and change:
#ocsp.trx-log = false
to
ocsp.trx-log = true
then uncomment the other lines below that starts with ocsp.trx-log. Change the ocsp.trx-log-log-date line if you want to change how the time recorded in logging should be output. The value should be on the same format as for javas DateFormat, information on valid configurations can be found at:http://javatechniques.com/blog/dateformat-and-simpledateformat-examples/
ocsp.trx-log-log-date = yyyy-MM-dd:HH:mm:ss
ocsp.trx-log-pattern is a pattern for use with ocsp.audit-order to replace constants with values during logging For most purposes you will not need to change this string.
Use ocsp.trx-log-order to specify what information should be logged and in what order. You can also configure what characters you want in between. If you want your log to display all of the values available you only have to un-comment it.
Available values for the transaction log are:
LOG_ID, An integer identifying that starts from 1 and is increased for every received request.
SESSION_ID A random 32 Byte long String generated when the OCSP-responder is started.
STATUS, The status of the OCSP-Request. SUCCESSFUL = 0;MALFORMED_REQUEST = 1;INTERNAL_ERROR = 2;TRY_LATER = 3;SIG_REQUIRED = 5;UNAUTHORIZED = 6;
CLIENT_IP, IP of the client making the request.
REQ_NAME, The Common Name (CN) of the client making the request.
SIGN_ISSUER_NAME_DN, DN of the issuer of the certificate used to sign the request.
SIGN_SUBJECT_NAME, Subject Name of the certificate used to sign the request.
SIGN_SERIAL_NO, Certificate serial number of the certificate used to sign the request.
NUM_CERT_ID, The number of certificates to check revocation status for.
ISSUER_NAME_DN, The subject DN of the issuer of a requested certificate.
ISSUER_NAME_HASH, MD5 hash of the issuer DN.
ISSUER_KEY, The public key of the issuer of a requested certificate.
DIGEST_ALGOR, Algorithm used by requested certificate to hash issuer key and issuer name.
SERIAL_NO, Serial number of the a requested certificate.
CERT_STATUS, The requested certificate revocation status.
REPLY_TIME, The time measured between when the request is received by the responder and when the response is sent. This time includes the time it takes to read the request bytes.
PROCESS_TIME, The time measured between when the request has been read by the responder and when the response is sent. This time starts after the request bytes have been read.
3. The OCSP audit log logs entire requests and responses. This can be useful when requests and responses are signed because the information can be used
to verify requests and responses afterwards.
Audit logging is configured in the same way as transaction logging.
Valid values for audit logging are:
LOG_ID, An integer identifying that starts from 1 and is increased for every received request.
SESSION_ID A random 32 Byte long String generated when the OCSP-responder is started.
OCSPREQUEST, The byte[] ocsp-request that came with the http-request.
OCSPRESPONSE, The byte[] ocsp-response that was included in the http-response.
Note that LOG_ID are of the same value in both trx log and audit log for any request. This means they can be cross referenced. You can retrieve information from the transaction log and verify that the information is valid by using the audit Log.
Configuring output files for OCSP logging
For JBoss you can configure JBOSS_HOME/server/default/conf/jboss-log4j.xml to put the transaction and audit logs in separate files.
<appender name="OCSPTRANSACTION" class="org.jboss.logging.appender.RollingFileAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
<param name="File" value="${jboss.server.log.dir}/transactions.log"/>
<param name="Append" value="false"/>
<param name="MaxFileSize" value="500KB"/>
<param name="MaxBackupIndex" value="1"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p [%c] %m%n"/>
</layout>
</appender>
<appender name="OCSPAUDIT" class="org.jboss.logging.appender.RollingFileAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
<param name="File" value="${jboss.server.log.dir}/audit.log"/>
<param name="Append" value="false"/>
<param name="MaxFileSize" value="500KB"/>
<param name="MaxBackupIndex" value="1"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p [%c] %m%n"/>
</layout>
</appender>
<category name="org.ejbca.core.protocol.ocsp.TransactionLogger">
<priority value="DEBUG"/>
<appender-ref ref="OCSPTRANSACTION"/>
</category>
<category name="org.ejbca.core.protocol.ocsp.AuditLogger">
<priority value="DEBUG"/>
<appender-ref ref="OCSPAUDIT"/>
</category>
For other application servers you can configure conf/log4j.properties and configure to use that configuration file in conf/ejbca.properties.
Safer Log4j Logging
The default behavior when logging fails, such as when the destination disk is full or disconnected, is to continue responding as normal. If you prefer the responder not to send OCSP-responses when logging fails you can use the following configuration:
1. From your EJBCA folder, run:
ant jbosslog4jsafer
2. Copy jbosslog4jsafer.jar from the dist directory to your JBoss Servers lib directory. For example:
cp dist/jbosslog4jsafer.jar /home/jboss/jboss-4.2.2.GA/server/default/lib/
3. Set 'ocsp.log-safer = true' in ocsp.properties
4. Modify your jboss-log4j.xml file to use the SaferDailyRollingFileAppender and ProbeableErrorHandler. For example:
<appender name="OCSPTRANSACTION" class="org.ejbca.appserver.jboss.SaferDailyRollingFileAppender">
<errorHandler class="org.ejbca.appserver.jboss.ProbeableErrorHandler" />
<param name="File" value="${jboss.server.log.dir}/transactions.log" />
<param name="Append" value="true" />
<!-- Rollover at midnight each day -->
<param name="DatePattern" value="'.'yyyy-MM-dd" />
<layout class="org.apache.log4j.PatternLayout">
<!-- The default pattern: Date Priority [Category] Message\n -->
<param name="ConversionPattern" value="%d %-5p [%c] %m%n" />
</layout>
</appender>
<appender name="OCSPAUDIT" class="org.ejbca.appserver.jboss.SaferDailyRollingFileAppender">
<errorHandler class="org.ejbca.appserver.jboss.ProbeableErrorHandler" />
<param name="File" value="${jboss.server.log.dir}/audit.log" />
<param name="Append" value="true" />
<!-- Rollover at midnight each day -->
<param name="DatePattern" value="'.'yyyy-MM-dd" />
<layout class="org.apache.log4j.PatternLayout">
<!-- The default pattern: Date Priority [Category] Message\n -->
<param name="ConversionPattern" value="%d %-5p [%c] %m%n" />
</layout>
</appender>
<logger name="org.ejbca.core.protocol.ocsp.TransactionLogger">
<level value="DEBUG" />
<appender-ref ref="OCSPTRANSACTION" />
</logger>
<logger name="org.ejbca.core.protocol.ocsp.AuditLogger">
<level value="DEBUG" />
<appender-ref ref="OCSPAUDIT" />
</logger>
If you use category instead of logger Log4j will output warnings on startup
5. Start JBoss and you are ready.
Setting up the Unid-Fnr OCSP extension
Configuring the Unid lookup server
The OCSP responder comes with an extension for looking up Unid-Fnr mappings. To enable the Unid extension you configure the options:
ocsp.extensionoid=2.16.578.1.16.3.2 ocsp.extensionclass=org.ejbca.core.protocol.ocsp.OCSPUnidExtension
in conf/ejbca.properties of the OCSP responder. All options are described in ejbca.properties.sample. There are three options for the Unid extension itself:
1. ocsp.uniddatsource
This should be set to a datasource configured in JBoss that goes to the correct database.
the database must contain the table according to the (MySQL) definition:
CREATE TABLE UnidFnrMapping(
unid varchar(250) NOT NULL DEFAULT '',
fnr varchar(250) NOT NULL DEFAULT '',
PRIMARY KEY (unid)
);
Example of ocsp.uniddatsource is java:/UnidDS, where UnidDS is configured similarly as EjbcaDS in JBOSS_HOME/server/default/deploy/ejbca-ds.xml, but using another database.
2. ocsp.unidtrustdir
All clients that will be allowed to lookup Unid-Fnr mapping must be issued a client certificate.
The issuer of the client certificates must be the same as the issuer of the server certificate for TLS
communication with the OCSP server (see below).
You should use these parameters (where differing from default) when issuing keystores to the clients:
- PKCS#12 files
- Extended key usage 'TLS client'
When a certificate has been issued for a lookup client, you must download the certificate from the admin-GUI of the CA and place it in ocsp.unidtrustdir. When a new certificate has been added, the OCSP application on the JBoss server must be re-deployed (you can do this with the command 'touch ejbca.ear' in JBOSS_HOME/server/default/deploy).
3. ocsp.unidcacert This is the CA certificate, in PEM format, that signed the certificates in ocsp.unidtrustdir. You can download it in PEM-format from EJBCA.
Configuring TLS on the Unid lookup server
If you are running the OCSP server integrated with EJBCA you do not have to bother with this, as EJBCA set up TLS for you.
On a stand alone OCSP server you must configure TLS with client authentication. To do this you first need a JKS keystore for
the key and certificate for the server.
You should use these parameters (where differing from default) when issuing keystores to the TLS servers:
- JKS files
- Key usage: Digital Signature, Key Encipherment
- Extended key usage: 'TLS server'
The Common Name (CN) for a TLS server should be the same as the machines fully qualified DNS name used to call the server. For example 'CN=ocsp.primekey.se'.The other DN components you can choose freely.
Once the JKS keystore is issued you can configure TLS on the OCSP server in the same way as on the EJBCA server.
It is configured in the file JBOSS_HOME/server/default/deploy/jboss-web.deployer/server.xml on the CA server.
The Connectors for port 8442 and 8443 is the TLS configuration.
The keystoreFile, keystorePass, truststoreFile and truststorePass are important to get right.
It is easiest if you put the keystore for the TLS server in the file p12/tomcat.jks on the external OCSP responder.
When doing this it should be deployed correctly when using 'ant ocsp-deploy', and you don't have to change the server.xml file which is
over-written by 'ant ocsp-deploy'.
Using database integrity protection
Enable the basic support for database protection as described in the section about Log signing in EJBCA Administrator section at wiki.ejbca.org. (you don't have to enable log signing though) and then select 'Database Integrity Protection' in the External OCSP Publisher.
Thats all there is to it. When EJBCA publishes certificate entries to the OCSP responder database, it will also write entries in the TableProtectData table. If protection is enabled also on the External OCSP responder, it will log errors:
PROTECT ERROR
if verification fails when it answers OCSP queries (this will slow it down a little bit).
If protection is not enabled on the External OCSP responder, it will not verify the entries when answering OCSP queries,
a remote batch job can be used to verify the database integrity periodically instead.
OCSP GET
The GET OCSP request is defined in RFC 2560 A.1.1 as: 'GET {url}/{url-encoding of base-64 encoding
of the DER encoding of the OCSPRequest}'. A base64-encoded request can contain the reserved
characters '+', '/' and '=', but will be handled correctly both in their %-escaped and original form
by the responder, since it's unclear if they do conflict as defined in RFC 2395 2.2.
Not all web-product handles the encoded '/' (%2F) nicely. JBoss/Tomcat has to be started with
-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true added to JAVA_OPT in
JBOSS_HOME/bin/run.conf.
Responses with longer validity and caching
RFC 2560 defines thisUpdate, nextUpdate and producedAt. producedAt is always included in the response and is the time the response was created. thisUpdate and nextUpdate is enabled by configuring 'ocsp.untilNextUpdate' in ocsp.properties. thisUpdate will be the time a singleResponse is embedded in the main response and nextUpdate will be 'untilNextUpdate' seconds later than thisUpdate. This enables clients that supports this feature to re-use a valid response and decrease to load on the OCSP-responder.
RFC 5019 defines how to use HTTP cache headers as defined in RFC 2616 for OCSP HTTP GET requests. By using the headers Last-Modified, Expires, max-age and Date, less intelligent nextwork component like HTTP caches can cache respones. This enables re-use of responses to decrease the load on the OCSP-responder and can shorten reponse times by deploying caches closer to the actual OCSP consumers. HTTP cache headers is enabled by configuring configuring 'ocsp.maxAge' in ocsp.properties
When using RFC 5019 style HTTP headers, JBoss users should be aware that the Date header is overwritten with a cached value. Since generating the Date-string is computationally heavy for regular small GET requests, it is generated about once per second. So a response will have a Last-Modified that is one second in the future from Date from time to time.
A regular Apache HTTP server can be used for caching requests, load-balancing and dropping some unwanted requests:
<VirtualHost *:80>
# Use as much memory as possible for the cache (in 1 kB blocks)
# 1GB of memory at ~2kB/ocsp request would hold about 500000 different requests
CacheEnable mem /
MCacheSize 1048576
MCacheMaxObjectCount 1000000
MCacheMinObjectSize 1
MCacheMaxObjectSize 4096
# Using disk-cache will allow a much larger pool of cached entires and the operation system
# will cache those files, but you are responsible for cleaning up old cache-entries using
# the "htcacheclean" tool. A disk cache will also live through a server restart.
# The user running apache has to have read/write access to "/var/cache/ocsp".
#CacheEnable disk /
#CacheRoot /var/cache/ocsp
# Ignore requests for uncached responses.. this will protect the OCSP from
# DOS attacks using "Cache-Control: no-cache" or "Pragma: no-cache"
CacheIgnoreCacheControl On
ProxyRequests Off
<Location>
# Everybody is welcome here..
Allow from all
Order allow,deny
# ..or just those from networks that is supposed to use the service
#Deny from all
#Order deny,allow
#allow from 127.
#allow from 172.16.212.1
ProxyPassReverse balancer://mycluster-kerb/
</Location>
# Proxy requests to OCSP instances (only one machine currently configured)
<Proxy balancer://mycluster-kerb>
# proxy_ajp has to be enabled for ajp-proxying
BalancerMember ajp://127.0.0.1:8009/ejbca/publicweb/status/ocsp
# proxy_http has to be enabled for http-proxying
#BalancerMember http://ocsp2.domain.org:8080/ejbca/publicweb/status/ocsp
#BalancerMember http://ocsp3.domain.org:8080/ejbca/publicweb/status/ocsp
</Proxy>
# We only want RFC 5019 compliant URLs to be forwarded to the OCSP, the rest
# should get a "404 Not found" or "414 Request-URI Too Large."
LimitRequestLine 257
RewriteEngine On
RewriteCond %{REQUEST_METHOD} get [NC]
RewriteRule ^/([a-zA-Z0-9+=/]+)$ balancer://mycluster-kerb/$1 [P,L]
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel debug
CustomLog /var/log/apache2/access.log combined
ErrorLog /var/log/apache2/error.log
</VirtualHost>