Tuesday, December 29, 2009
FOSDEM 2010
Yes, EJBCA and SignServer will have a stand at the geek fest FOSDEM on the 6-7 february 2010. Visit FOSDEM, it's great!
Using Brainpool ECC curves in Java (with HSM)
In EAC ePassports the Brainpool family of curves can be used, and is used by some countries. Java (or more specifically the Sun JCE and PKCS#11 provider) does not have support for this curve naturally, it is not a named curve that it knows about. The kind guys over at Ministerie van Binnenlandse Zaken en Koninkrijksrelaties in Netherlands experimented and showed us how to use it with a SafeNet ProtectServer Gold.
I tested it out and wrote a howto for EJBCA. The downside is that you have to generate the keys with the HSM tools, so you can not generate new keys from within the EJBCA admin gui.
Of course if you are not using an HSM, the Bouncycastle provider has support for them out of the box.
I tested it out and wrote a howto for EJBCA. The downside is that you have to generate the keys with the HSM tools, so you can not generate new keys from within the EJBCA admin gui.
Of course if you are not using an HSM, the Bouncycastle provider has support for them out of the box.
Monday, December 21, 2009
EJBCA 3.9.3 released
Very convenient, so you have something to play with during the christmas holidays...here is EJBCA 3.9.3.
This is a minor release but packed with new minor features and fixes, 42 issues have been resolved.
Some minor features and options and some bug fixes and stabilizations.
Noteworthy changes:
- Fixed a regression in 3.9.2 where you could not upload files in the admin GUI.
- Certificate profiles can now specify a different signature algorithm than the CA. Useful to start migrating SHA1 CAs to issue SHA256 certificates.
- Possibility to use part of user data in LDAP DN but not in certificate DN when publishing certificate to LDAP.
- Possibility to set fixed end date of certificates in certificate profile and CA configuration.
- Possibility to configure several notification services for expiring certificates, notifying at different times, i.e. 30 days, 7 days, etc.
- Browser enrollment tested with Windows 7.
- ECC improvements and fixes for CAs and HSMs, CA renew keys, CA import, brainpool curves, explicit ec parameters, clientToolBox etc.
- GUI improvement to the admin GUI with nicer navigation menu and CSS. Contributed by Linagora, France.
- cert-cvc: fixed rare possibility to get bad encoding of EC points in certificates. Contributed by DGBK, Netherlands.
- CVC CA fixes and improvements for EAC PKI, approvals, import CAs, fix cli info command, .cvcert instear of .crt when downloading certs, etc.
- Don't publish certificates for inactive CA services to LDAP.
- Fix so renewing CA keys in admin GUI does not reload all CA tokens.
- Fixed an OutOfMemory error when failing to publish large CRLs with connection closed error.
- Fix download issues with IE for exported CA keystores.
- Many small optimizations, fixes and improvements.
Read the full changelog for details.
This is a minor release but packed with new minor features and fixes, 42 issues have been resolved.
Some minor features and options and some bug fixes and stabilizations.
Noteworthy changes:
- Fixed a regression in 3.9.2 where you could not upload files in the admin GUI.
- Certificate profiles can now specify a different signature algorithm than the CA. Useful to start migrating SHA1 CAs to issue SHA256 certificates.
- Possibility to use part of user data in LDAP DN but not in certificate DN when publishing certificate to LDAP.
- Possibility to set fixed end date of certificates in certificate profile and CA configuration.
- Possibility to configure several notification services for expiring certificates, notifying at different times, i.e. 30 days, 7 days, etc.
- Browser enrollment tested with Windows 7.
- ECC improvements and fixes for CAs and HSMs, CA renew keys, CA import, brainpool curves, explicit ec parameters, clientToolBox etc.
- GUI improvement to the admin GUI with nicer navigation menu and CSS. Contributed by Linagora, France.
- cert-cvc: fixed rare possibility to get bad encoding of EC points in certificates. Contributed by DGBK, Netherlands.
- CVC CA fixes and improvements for EAC PKI, approvals, import CAs, fix cli info command, .cvcert instear of .crt when downloading certs, etc.
- Don't publish certificates for inactive CA services to LDAP.
- Fix so renewing CA keys in admin GUI does not reload all CA tokens.
- Fixed an OutOfMemory error when failing to publish large CRLs with connection closed error.
- Fix download issues with IE for exported CA keystores.
- Many small optimizations, fixes and improvements.
Read the full changelog for details.
Sunday, December 13, 2009
EJBCA PKI webcasts
There is a series of webcasts about PKI in general and EJBCA in particular. Watch these cool clips at http://www.primekey.se/Company/Webcasts/.
Friday, November 27, 2009
EJBCA and OpenSSO integration
EJBCA and OpenSSO are great companions. EJBCA provides users with digital certificates for strong authentication and digital signatures, and OpenSSO uses these credentials to provide single sign-on and authorization. Using the latest buzzwords such as SAML, XACML etc.
Over at ejbca.org we have a couple of great articles how to set up integration between EJBCA and OpenSSO and how to configure the Certificate authentication module in OpenSSO. Issue a certificate in EJBCA and immediately use it to authenticate with OpenSSO.
Check out the EJBCA-OpenSSO articles at EJBCA.org.
Over at ejbca.org we have a couple of great articles how to set up integration between EJBCA and OpenSSO and how to configure the Certificate authentication module in OpenSSO. Issue a certificate in EJBCA and immediately use it to authenticate with OpenSSO.
Check out the EJBCA-OpenSSO articles at EJBCA.org.
Monday, November 23, 2009
MySQL on a SSD disk
I thought that my MySQL InnoDB database was a bit slow, at least when running on an encrypted disk. Added a 80GB X25-M SSD disk to keep the MySQL database on (only development data so no encryption needed there). My performance increased 5 times as worst and more then 10 times at best.
Application with a lot of short database access (such as large update statements in mysql) will get a huge boost with SSD. We will see how it performs in the long run...
So far it is highly recommended!
Bind-mount is really good:
mount -B /media/SSD/mysql /var/lib/mysql
or in fstab:
/media/SSD/mysql /var/lib/mysql bind defaults,bind 0 0
Did all this to get up the speed when producing really large CRLs (>500.000 revoked certificates). Works pretty neat.
Application with a lot of short database access (such as large update statements in mysql) will get a huge boost with SSD. We will see how it performs in the long run...
So far it is highly recommended!
Bind-mount is really good:
mount -B /media/SSD/mysql /var/lib/mysql
or in fstab:
/media/SSD/mysql /var/lib/mysql bind defaults,bind 0 0
Did all this to get up the speed when producing really large CRLs (>500.000 revoked certificates). Works pretty neat.
Thursday, November 5, 2009
USB pass-through to KVM in Ubuntu Karmic (9.10)
You have to allow lib-virt to use USB devices.
Edit /etc/apparmor.d/abstractions/libvirt-qemu and uncomment some lines.
# WARNING: uncommenting these gives the guest direct access to host hardware.
# This is required for USB pass through but is a security risk. You have been
# warned.
/sys/bus/usb/devices/ r,
/sys/devices/*/*/usb[0-9]*/** r,
/dev/bus/usb/*/[0-9]* rw,
Migrating vmware images to use in kvm instead is nicely described here: http://ubuntuforums.org/showthread.php?t=1163175.
For a RedHat image I simply ran:
sudo qemu-img convert -f vmdk redhat.vmdk -O qcow2 redhat.img
Create a new kvm machine in virt-manager, but temrinate when it tries to start installing. Simply reaplce the image virt-manager created with redhat.img and restart the new kvm machine.
Edit /etc/apparmor.d/abstractions/libvirt-qemu and uncomment some lines.
# WARNING: uncommenting these gives the guest direct access to host hardware.
# This is required for USB pass through but is a security risk. You have been
# warned.
/sys/bus/usb/devices/ r,
/sys/devices/*/*/usb[0-9]*/** r,
/dev/bus/usb/*/[0-9]* rw,
Migrating vmware images to use in kvm instead is nicely described here: http://ubuntuforums.org/showthread.php?t=1163175.
For a RedHat image I simply ran:
sudo qemu-img convert -f vmdk redhat.vmdk -O qcow2 redhat.img
Create a new kvm machine in virt-manager, but temrinate when it tries to start installing. Simply reaplce the image virt-manager created with redhat.img and restart the new kvm machine.
SignServer 3.1.0 released
The PrimeKey SignServer team is happy to announce that SignServer 3.1 has been
released! This is a major new version with lots of exciting functionality for document signing and validation.
Development continues beyond this version and all requests from the community and from the EJBCA Developer Conference [1] are scheduled for SignServer 3.2 or later releases.
More information is available at the project web site [2] and the complete changelog can be viewed in the issue tracker [3].
SignServer 3.1 Release Notes ►
[2] http://www.signserver.org
[3] http://jira.primekey.se/browse/DSS
released! This is a major new version with lots of exciting functionality for document signing and validation.
Development continues beyond this version and all requests from the community and from the EJBCA Developer Conference [1] are scheduled for SignServer 3.2 or later releases.
More information is available at the project web site [2] and the complete changelog can be viewed in the issue tracker [3].
SignServer 3.1 Release Notes ►
- New module system: The byte code for a worker can be packaged as a separate module that can be loaded and unloaded at runtime.
- New workers: XML Signer/Validator - Signing and validating XML documents. ODF Signer - Signing Open Document Format documents, for instance used by OpenOffice.org. OOXML Signer - Signing Office Open XML documents. CRL Validator - Validating certificates by looking up certificate revocation lists. OCSP Validator - Validating certificates using the online certificate status protocol. MRTD SOD Signer - Creating and signing ePassport security objects.
- Several other minor features, fixes and improvements.
[2] http://www.signserver.org
[3] http://jira.primekey.se/browse/DSS
Wednesday, October 21, 2009
EJBCA 3.9.2 released
We are proud to announce the release of EJBCA 3.9.2. We believe this is
the most stable release of EJBCA to date.
This is a minor release but packed with new minor features and fixes, 38
issues have been resolved. Some minor features and options and many bug
fixes and stabilizations.
Noteworthy changes:
- Sign and verify of files with clientToolBox when the private key is
stored on a HSM.
- Possible to limit signing keys for an external OCSP responder to keys
within a set of key aliases.
- Add support for the TSL signer extended key usage
- Use improved validity period parsing in Certificate Profiles
- Add option to use publisher queue or not for CRLs and certificates
- Document MS application policies extension
- Fixes for ejbcaClientToolBox.bat for windows platform
- Timeouts for LDAP publishers to handle unstable LDAP servers
- For issue where CRL service may stop running if database is stopped
for some period
- Change so that Issuing Distribution Point on CRLs is not used by
default in CA configuration
- Fix issue using IAIK provider with several CAs
- Fix slow revocation if a user have many certificates
- cert-cvc: getting expiration date returns 00.00 hours but it means
it's valid the whole day
- cert-cvc: bad encoding of EC points in certificates in rare cases
where affineX and affineY is not same size
- Many small optimizations, fixes and improvements.
Read the full changelog for details.
For upgrade instructions, please see UPGRADE.
----
Work has already started for EJBCA 3.9.3, as well as 3.10. For 3.9.3 we
will for the first time in ages get some new bling on the admin GUI,
thanks to David Carella in France who contributed some styles for the
admin GUI.
EJBCA 3.10 will have many changes, preparing for the big move to EJBCA
4.0. Among other things all configuration in properties files are now
possible to store outside of the ear file, and change dynamically in
runtime.
Regards,
The EJBCA team at PrimeKey.
the most stable release of EJBCA to date.
This is a minor release but packed with new minor features and fixes, 38
issues have been resolved. Some minor features and options and many bug
fixes and stabilizations.
Noteworthy changes:
- Sign and verify of files with clientToolBox when the private key is
stored on a HSM.
- Possible to limit signing keys for an external OCSP responder to keys
within a set of key aliases.
- Add support for the TSL signer extended key usage
- Use improved validity period parsing in Certificate Profiles
- Add option to use publisher queue or not for CRLs and certificates
- Document MS application policies extension
- Fixes for ejbcaClientToolBox.bat for windows platform
- Timeouts for LDAP publishers to handle unstable LDAP servers
- For issue where CRL service may stop running if database is stopped
for some period
- Change so that Issuing Distribution Point on CRLs is not used by
default in CA configuration
- Fix issue using IAIK provider with several CAs
- Fix slow revocation if a user have many certificates
- cert-cvc: getting expiration date returns 00.00 hours but it means
it's valid the whole day
- cert-cvc: bad encoding of EC points in certificates in rare cases
where affineX and affineY is not same size
- Many small optimizations, fixes and improvements.
Read the full changelog for details.
For upgrade instructions, please see UPGRADE.
----
Work has already started for EJBCA 3.9.3, as well as 3.10. For 3.9.3 we
will for the first time in ages get some new bling on the admin GUI,
thanks to David Carella in France who contributed some styles for the
admin GUI.
EJBCA 3.10 will have many changes, preparing for the big move to EJBCA
4.0. Among other things all configuration in properties files are now
possible to store outside of the ear file, and change dynamically in
runtime.
Regards,
The EJBCA team at PrimeKey.
Friday, September 25, 2009
Presentation from EJBCA Developers conference
We held an EJBCA developers conference in Sweden on the 13-15 of September. Some presentations from the conference are now up on http://www.primekey.se/Community/.
/Tomas
/Tomas
Thursday, September 3, 2009
Open Source security project gets EU funding
Article (in Swedish) about PrimeKey Solutions (in a consortium that the article does not mention) getting funding for developing an EAL certified open source security core.
http://www.idg.se/2.1085/1.243826/eu-miljoner-till-svenska-it-foretag
http://www.idg.se/2.1085/1.243826/eu-miljoner-till-svenska-it-foretag
Friday, August 21, 2009
JMRTD and ISODL
JMRTD and ISODL are two open source projects that are using the cert-cvc library available in EJBCA. Cert-cvc was created for handling the CVC certificates used for EU EAC ePassports. The ISODL project uses the library, slightly modified, to handle CVC certificates used for driving licenses. JMRTD has build a complete library for handling the different parts of ePassports, not only EAC. Using JMRTD for example we built a MRTD SO signer in SignServer, that takes data group hashes and returns a finished signed SO(d).
Open source is great!
Cert-cvc: http://www.ejbca.org/.
JMRTD: http://www.jmrtd.org/
ISODL: http://isodl.sourceforge.net/
Open source is great!
Cert-cvc: http://www.ejbca.org/.
JMRTD: http://www.jmrtd.org/
ISODL: http://isodl.sourceforge.net/
Monday, August 17, 2009
EJBCA 3.9.1 released
We are pleased to announce the release of EJBCA 3.9.1.
This is a minor release but packed with new minor features and fixes, 46
issues have been resolved.
Noteworthy changes:
- Improvements to public enrollment process including automatic renewal.
- Ability to specify approvals on certificate profiles.
- Configurable list of extended key usages.
- Dynamic update of max-age and nextUpdate for OCSP responders, also per
certificate profile.
- In CRL update service you can select which CAs to generate CRLs for.
- Possible to schedule CRLs more often than hourly.
- Possible to remove soft CA key and possibility to import it back again.
- Possibility to remove passwords from properties files.
- Support for CRL distribution points with URI:s containing semicolon.
- Transaction log for web service certificate issuance.
- Possibility to specify Any CA in end entity profiles.
- More flexible configuration of CA validity, years, months days.
- Improved error message in GUI when HSM activation fails.
- Many small optimizations, fixes and improvements.
Read the full changelog for details.
https://jira.primekey.se/browse/ECA?report=com.atlassian.jira.plugin.system.project:changelog-panel
This is a plug-in upgrade for users of EJBCA 3.9.0.
Visit EJBCA.org to download the latest release!
Regards,
The EJBCA team.
This is a minor release but packed with new minor features and fixes, 46
issues have been resolved.
Noteworthy changes:
- Improvements to public enrollment process including automatic renewal.
- Ability to specify approvals on certificate profiles.
- Configurable list of extended key usages.
- Dynamic update of max-age and nextUpdate for OCSP responders, also per
certificate profile.
- In CRL update service you can select which CAs to generate CRLs for.
- Possible to schedule CRLs more often than hourly.
- Possible to remove soft CA key and possibility to import it back again.
- Possibility to remove passwords from properties files.
- Support for CRL distribution points with URI:s containing semicolon.
- Transaction log for web service certificate issuance.
- Possibility to specify Any CA in end entity profiles.
- More flexible configuration of CA validity, years, months days.
- Improved error message in GUI when HSM activation fails.
- Many small optimizations, fixes and improvements.
Read the full changelog for details.
https://jira.primekey.se/browse/ECA?report=com.atlassian.jira.plugin.system.project:changelog-panel
This is a plug-in upgrade for users of EJBCA 3.9.0.
Visit EJBCA.org to download the latest release!
Regards,
The EJBCA team.
Thursday, June 25, 2009
Accessing the WS signing certificate from inside a JAX-WS webservice
When I have set up the webservice as in the previous post to require signatures, it's very normal that I would like to know who signed the certificate. Also I probably want to access the credentials of the signature, in this case the certificate.
How do I retrieve the signature certificate of a WS-security signed SOAP message?
I could not find any good post describing this on the Internet...
Well here it is now:
How do I retrieve the signature certificate of a WS-security signed SOAP message?
I could not find any good post describing this on the Internet...
Well here it is now:
@Resource
private WebServiceContext wsContext;
<snip>
MessageContext mctx = wsContext.getMessageContext();
Subject s = (Subject)mctx.get("CLIENT_SUBJECT");
Set cs = s.getPublicCredentials();
for (Iterator iterator = cs.iterator(); iterator.hasNext();) {
Object object = (Object) iterator.next();
System.out.println("Object: "+object.getClass().getName());
if (object instanceof X509Certificate) {
System.out.println("Found a certificate");
X509Certificate cert = (X509Certificate) object;
System.out.println(cert.toString());
}
}
if (s != null) {
Setps = s.getPrincipals();
for (Iterator iterator = ps.iterator(); iterator.hasNext();) {
Principal principal = (Principal) iterator.next();
if (principal instanceof X500Principal) {
X500Principal xp = (X500Principal) principal;
System.out.println(xp.getName());
}
}
}
<snip>
Etiketter:
ws-security x.509 certificate signature
Monday, June 22, 2009
Configuring Glassfish and SOAPui to use message level security with digital signatures
I made a simple Jax-WS project with simple webservice. The tricky part is that I wanted message level security with WS-security digital signatures authenticating the message. It took me a while to get it right, so here is how it's done. You can configure WS-security layer on the server side simply by configuring Glassfish use it for all soap messaging. This was the easiest way for me to set it up.
* Configure glassfish:
This will use the default server keystore for signatures, the same keystore that is used for SSL.
In admin console go to: Configuration->Security->Message Security->SOAP
In Message Security tab select:
Default Provider: ServerProvider
Default Client Provider: ClientProvider
In Providers tab click ServerProvider:
Provider Type: server
class name (default): com.sun.xml.wss.provider.ServerSecurityAuthModule
Request policy:
- Authenticate Source: content
- Authenticate Recipient: null (blank)
Response policy:
- Authenticate Source: content
- Authenticate Recipient: null (blank)
Additional Properties:
leave as default
* Configure SOAPui
Create a project and send a message to the server. When the server is configured to require signature you should receive a "Error validating request" message back.
Open project view. Go to tab Security Configuration->Keystores/Certificates.
Add a keystore glassfish/domains/domain1/config/keystore.jks, password changeit and default alias s1as.
Change to tab Outgoing WS-Security Configurations. Create a new configuration called "sign".
Add a new WSS Entry called Timestamp with Time To Live 1000 (or something).
Add a new WSS Entry called Signature:
- Keystore: keystore.jks
- Alias: s1as
- Password: changeit
- Key Identifier Type: Binary Security Token
- Signature Algorithm: http://www.w3.org/2000/09/xmldsig#rsa-sha1
- Signature Canonicalization: http://www.w3.org/2001/10/xml-exc-c14n#
- Use single certificate for signing
- Add a new part: Name=Body, Namespace=http://schemas.xmlsoap.org/soap/envelope/, Encode=Element
- Add a new part: Name=Timestamp, Namespace=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd, Encode=Element
Finally in the request window add the configuration. Select XML view and click Aut in the bottom, select Outgoing WSS=Sign
Now you will probably have an issue with glassfish being unable to verify your message. This is due to canonicalization and SOAPui making nice display of the XML for you.
Go into the XML view and remove all whitespace and newlines in the soapenv:Body tag.
Now it should work!
* Configure glassfish:
This will use the default server keystore for signatures, the same keystore that is used for SSL.
In admin console go to: Configuration->Security->Message Security->SOAP
In Message Security tab select:
Default Provider: ServerProvider
Default Client Provider: ClientProvider
In Providers tab click ServerProvider:
Provider Type: server
class name (default): com.sun.xml.wss.provider.ServerSecurityAuthModule
Request policy:
- Authenticate Source: content
- Authenticate Recipient: null (blank)
Response policy:
- Authenticate Source: content
- Authenticate Recipient: null (blank)
Additional Properties:
leave as default
* Configure SOAPui
Create a project and send a message to the server. When the server is configured to require signature you should receive a "Error validating request" message back.
Open project view. Go to tab Security Configuration->Keystores/Certificates.
Add a keystore glassfish/domains/domain1/config/keystore.jks, password changeit and default alias s1as.
Change to tab Outgoing WS-Security Configurations. Create a new configuration called "sign".
Add a new WSS Entry called Timestamp with Time To Live 1000 (or something).
Add a new WSS Entry called Signature:
- Keystore: keystore.jks
- Alias: s1as
- Password: changeit
- Key Identifier Type: Binary Security Token
- Signature Algorithm: http://www.w3.org/2000/09/xmldsig#rsa-sha1
- Signature Canonicalization: http://www.w3.org/2001/10/xml-exc-c14n#
- Use single certificate for signing
- Add a new part: Name=Body, Namespace=http://schemas.xmlsoap.org/soap/envelope/, Encode=Element
- Add a new part: Name=Timestamp, Namespace=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd, Encode=Element
Finally in the request window add the configuration. Select XML view and click Aut in the bottom, select Outgoing WSS=Sign
Now you will probably have an issue with glassfish being unable to verify your message. This is due to canonicalization and SOAPui making nice display of the XML for you.
Go into the XML view and remove all whitespace and newlines in the soapenv:Body tag.
Now it should work!
Sunday, June 7, 2009
Build an open source enterprise OCSP validation service
Build a high performance OCSP responder using EJBCA. EJBCA is a J2EE enterprise open source PKI that you can deploy as a certificate authority or an ocsp responder.
EJBCA is a J2EE enterprise open source PKI that you can deploy as a certificate authority or an ocsp responder.
With the release fo EJBCA 3.9.0 it is easier than ever to set up a high performance, high reliability OCSP responder.
OCSP stands for online certificate status protocol and is defined in RFC2560. In short it provides an online service for validating that a certicate, as used by SSL or VPN etc, has not been revoked. OCSP has the basic functionality defined in RFC2560 and this, in it's plain form, it widely used. If using a high speed hardware security module (HSM) for signature operations you can easily answer 500 requests per second with the EJBCA external OCSP responder. Certificate status information is kept in a regular database, such as MySQL, making it very suitable for online services because you can really update the information on line without waiting for the certificate authority to issued certificate revocation lists (CRLs).
To further improve scalability of OCSP IETF has defined a lighweight OCSP profile in RFC5019. This profile builds on the usage of http get instead of http post which is the default transport used. Using http get the responder can set http headers to enable caching by regular proxies. Caching makes the service slightly less online, in the meaning that you always gets fresh information, but can improve performance across networks. EJBCA 3.9.0 improves the EJBCA external OCSP responder with full support for RFC5019.
If you plan on building an OCSP service there are many things to consider:
- standards support
- performance
- scalability by adding cluster nodes
- transaction and audit logging
- authentication of callers, possibly requiring signed requests
- use of custom OCSP extensions
- OCSP responder independent of CA service provider
- renewal of OCSP responder keys
A typical configuration for OCSP uses two or more OCSP responder nodes. Each OCSP responder keeps it's own database. By using it's own database you can assure truly high availability because the nodes are completely independent and you can do maintenance on one node, including the database, without affecting uptime of the service. The OCSP responder nodes should be connected to a set of HSMs in a high availability setup, if one HSM breaks, another keeps the service running albeit with less available performance.
Each OCSP responder will produce full transaction and audit logging. Audit logging is needed in order to maintain trust, since a validation service such as OCSP is about trust. Transaction logging will be needed if you want to keep records of users of the service either for billing purposes or to keep statistics.
Visit EJBCA.org for downloads and documentation.
EJBCA is a J2EE enterprise open source PKI that you can deploy as a certificate authority or an ocsp responder.
With the release fo EJBCA 3.9.0 it is easier than ever to set up a high performance, high reliability OCSP responder.
OCSP stands for online certificate status protocol and is defined in RFC2560. In short it provides an online service for validating that a certicate, as used by SSL or VPN etc, has not been revoked. OCSP has the basic functionality defined in RFC2560 and this, in it's plain form, it widely used. If using a high speed hardware security module (HSM) for signature operations you can easily answer 500 requests per second with the EJBCA external OCSP responder. Certificate status information is kept in a regular database, such as MySQL, making it very suitable for online services because you can really update the information on line without waiting for the certificate authority to issued certificate revocation lists (CRLs).
To further improve scalability of OCSP IETF has defined a lighweight OCSP profile in RFC5019. This profile builds on the usage of http get instead of http post which is the default transport used. Using http get the responder can set http headers to enable caching by regular proxies. Caching makes the service slightly less online, in the meaning that you always gets fresh information, but can improve performance across networks. EJBCA 3.9.0 improves the EJBCA external OCSP responder with full support for RFC5019.
If you plan on building an OCSP service there are many things to consider:
- standards support
- performance
- scalability by adding cluster nodes
- transaction and audit logging
- authentication of callers, possibly requiring signed requests
- use of custom OCSP extensions
- OCSP responder independent of CA service provider
- renewal of OCSP responder keys
A typical configuration for OCSP uses two or more OCSP responder nodes. Each OCSP responder keeps it's own database. By using it's own database you can assure truly high availability because the nodes are completely independent and you can do maintenance on one node, including the database, without affecting uptime of the service. The OCSP responder nodes should be connected to a set of HSMs in a high availability setup, if one HSM breaks, another keeps the service running albeit with less available performance.
Each OCSP responder will produce full transaction and audit logging. Audit logging is needed in order to maintain trust, since a validation service such as OCSP is about trust. Transaction logging will be needed if you want to keep records of users of the service either for billing purposes or to keep statistics.
Visit EJBCA.org for downloads and documentation.
EJBCA 3.9.0 released
After much hard work, EJBCA 3.9.0 is finally released. This might just
be the best release ever of EJBCA :-)
This is a major release adding many new features and improvements, and fixing numerous bugs.
126 issues have been resolved for this release. Check the changelog, there is a good chance that your favorite issue has been resolved.
Some noteworthy changes:
- Support for CAs using DSA keys. EJBCA now supports all major algorithms; RSA, DSA and ECDSA.
- External RA improvements. CA service running as an EJBCA services gives full cluster functionality and support for multiple external RAs. As a bonus it is now much easier to install and configure.
- Robust re-publishing mechanism for publishers that fail, running as an
EJBCA service.
- OCSP responder improvements with performance improvements and support
for on-line renewal of OCSP responder keys and certificates. The external OCSP responder can now saturate high performance HSMs.
- OCSP monitoring tool for monitoring synchronization between EJBCA and
external OCSP responders.
- GUI for configuring the external OCSP publisher with new options.
- Possible to change OCSP signing keys in a running external OCSP responder.
- New commands and stress tests in the client toolbox.
- A new admin web gui front page with status overview panels.
- Possible to configure status of certificates issued for end entities, i.e. issue certificate revoked "on hold".
- New DN attribute, Name.
- Performance improvement by caching and lowering number of database queries.
- XKMS now works also on Java 6.
- Possibility to set user validity start and end time in WS API.
- Lots of small fixes and improvements to the admin GUI.
- Lots of small bugfixes.
- Keon CA to EJBCA migration guide.
Note that the configuration of External RA changed dramatically (to the better). If using the external RA, please read the manual how to install and configure the RA CA service in EJBCA 3.9.
Note that this version brings database changes. Read the UPGRADE document for upgrade instructions.
This release should, as always, work on JBoss, Glassfish, Weblogic and OC4J, together with most available databases.
Read the changelog for details.
be the best release ever of EJBCA :-)
This is a major release adding many new features and improvements, and fixing numerous bugs.
126 issues have been resolved for this release. Check the changelog, there is a good chance that your favorite issue has been resolved.
Some noteworthy changes:
- Support for CAs using DSA keys. EJBCA now supports all major algorithms; RSA, DSA and ECDSA.
- External RA improvements. CA service running as an EJBCA services gives full cluster functionality and support for multiple external RAs. As a bonus it is now much easier to install and configure.
- Robust re-publishing mechanism for publishers that fail, running as an
EJBCA service.
- OCSP responder improvements with performance improvements and support
for on-line renewal of OCSP responder keys and certificates. The external OCSP responder can now saturate high performance HSMs.
- OCSP monitoring tool for monitoring synchronization between EJBCA and
external OCSP responders.
- GUI for configuring the external OCSP publisher with new options.
- Possible to change OCSP signing keys in a running external OCSP responder.
- New commands and stress tests in the client toolbox.
- A new admin web gui front page with status overview panels.
- Possible to configure status of certificates issued for end entities, i.e. issue certificate revoked "on hold".
- New DN attribute, Name.
- Performance improvement by caching and lowering number of database queries.
- XKMS now works also on Java 6.
- Possibility to set user validity start and end time in WS API.
- Lots of small fixes and improvements to the admin GUI.
- Lots of small bugfixes.
- Keon CA to EJBCA migration guide.
Note that the configuration of External RA changed dramatically (to the better). If using the external RA, please read the manual how to install and configure the RA CA service in EJBCA 3.9.
Note that this version brings database changes. Read the UPGRADE document for upgrade instructions.
This release should, as always, work on JBoss, Glassfish, Weblogic and OC4J, together with most available databases.
Read the changelog for details.
Monday, May 11, 2009
New status overview in the EJBCA admin GUI
In EJBCA 3.9 the admin GUI will get it's first really nice update in a year or so. Apart from the usual additional options etc that pops up in every release, this release changes a fundamental concept - the first page.
We have long been thinking about have the first page be a kind of portal page where an administrator can get an overview of important status and information of the system. Originally we was planning this for the major re-make of the admin gui planned for 4.1. In 3.9 we got the opportunity, thanks to corporate sponsored development and our new developer Markus.
The first page meeting the administrator now has two panels- One with an overview of CAs on-line/off-line status and CRL status and one with number of pending publisher queue items (new feature in 3.9).
We even got some new style sheet items in there :-).
Combined with the on-line documentation links from the admin GUI (question marks in the image) it's really nice.
View a full set of screen shots at sourceforge.
We have long been thinking about have the first page be a kind of portal page where an administrator can get an overview of important status and information of the system. Originally we was planning this for the major re-make of the admin gui planned for 4.1. In 3.9 we got the opportunity, thanks to corporate sponsored development and our new developer Markus.
The first page meeting the administrator now has two panels- One with an overview of CAs on-line/off-line status and CRL status and one with number of pending publisher queue items (new feature in 3.9).
We even got some new style sheet items in there :-).
Combined with the on-line documentation links from the admin GUI (question marks in the image) it's really nice.
View a full set of screen shots at sourceforge.
Sunday, April 26, 2009
Migrating ext3 to ext4 on an encrypted root disk (ubuntu 9.04)
Ext4 is supposed to be much faster than ext3. Anything that makes development of EJBCA a bit quicker is interesting, so I just had to migrate to ext4 now that Ubuntu 9.04 is out.
The usual ext3 to ext4 migration guides are for normal unencrypted disk. Since my laptop has full disk enryption a few addition steps are needed.
Also the guides mention that you have to do 'grub-install' after migration. I did not have to do that.
Either it is because:
- I only migrated / and not /boot
- The standard upgrade to Ubuntu 9.04 already installed a new grub for me.
Anyhow, here are the steps hwo to migrate an encrypted root disk from ext3 to ext4.
Shut down computer properly, don't hibernate.
Boot from Ubuntu 9.04 cd and use it as a live cd (no changes to computer).
Open a terminal and become root.
#sudo su -
Set up crypto add encrypted disk to lvm
#cryptsetup luksOpen /dev/sda1 root
#lvm vgchange -a y
Mount root disk and just check that it's the correct disk before migrating
#mkdir /mnt/root
#mount /dev/tlap/root /mnt/root
Unmount and do the migration to ext4 (as described in the ext4 wiki and numerous other sites)
#umount /mnt/root/
#tune2fs -O extents,uninit_bg,dir_index /dev/tlap/root
#e2fsck -pfD /dev/tlap/root
Mount new ext4 disk and change fstab to ext4
#mount /dev/tlap/root /mnt/root
#cd /mnt/root/etc/
#vi fstab
Change ext3 to ext4 for you / disk (/dev/sda1 for me).
# /dev/mapper/tlap-root
UUID=ca86bf3d-40fb-4b4d-89c6-15ce94674fa0 / ext4 relatime,errors=remount-ro 0 1
Save, unmount /mnt/root and reboot.
After reboot check /etc/fstab and 'mount' and you will see that it's ext4 now.
tomas@tlap:~/tmp$ mount
/dev/mapper/tlap-root on / type ext4 (rw,relatime,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
...
Update:
I migrated my rather slowish home computer (AMD 4200+, 4GB, WD Raptor) running 'ant clean; ant' both before and after migration. The conclusion is that it takes 1 minute, give or take a few seconds, on both ext3 and ext4. Not huge leaps in speed there unfortunately.
The usual ext3 to ext4 migration guides are for normal unencrypted disk. Since my laptop has full disk enryption a few addition steps are needed.
Also the guides mention that you have to do 'grub-install' after migration. I did not have to do that.
Either it is because:
- I only migrated / and not /boot
- The standard upgrade to Ubuntu 9.04 already installed a new grub for me.
Anyhow, here are the steps hwo to migrate an encrypted root disk from ext3 to ext4.
Shut down computer properly, don't hibernate.
Boot from Ubuntu 9.04 cd and use it as a live cd (no changes to computer).
Open a terminal and become root.
#sudo su -
Set up crypto add encrypted disk to lvm
#cryptsetup luksOpen /dev/sda1 root
#lvm vgchange -a y
Mount root disk and just check that it's the correct disk before migrating
#mkdir /mnt/root
#mount /dev/tlap/root /mnt/root
Unmount and do the migration to ext4 (as described in the ext4 wiki and numerous other sites)
#umount /mnt/root/
#tune2fs -O extents,uninit_bg,dir_index /dev/tlap/root
#e2fsck -pfD /dev/tlap/root
Mount new ext4 disk and change fstab to ext4
#mount /dev/tlap/root /mnt/root
#cd /mnt/root/etc/
#vi fstab
Change ext3 to ext4 for you / disk (/dev/sda1 for me).
# /dev/mapper/tlap-root
UUID=ca86bf3d-40fb-4b4d-89c6-15ce94674fa0 / ext4 relatime,errors=remount-ro 0 1
Save, unmount /mnt/root and reboot.
After reboot check /etc/fstab and 'mount' and you will see that it's ext4 now.
tomas@tlap:~/tmp$ mount
/dev/mapper/tlap-root on / type ext4 (rw,relatime,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
...
Update:
I migrated my rather slowish home computer (AMD 4200+, 4GB, WD Raptor) running 'ant clean; ant' both before and after migration. The conclusion is that it takes 1 minute, give or take a few seconds, on both ext3 and ext4. Not huge leaps in speed there unfortunately.
Thursday, April 23, 2009
What to do when you mac address of eth0 changed (debian/ubuntu)?
It always takes me too long to google up this answer so I'll write it here..
Either edit or delete this file:
/etc/udev/rules.d/70-persistent-net.rules
If you delete it, a reboot will create a new one with your new mac address.
Either edit or delete this file:
/etc/udev/rules.d/70-persistent-net.rules
If you delete it, a reboot will create a new one with your new mac address.
Tuesday, April 14, 2009
External RA improvements
In the upcoming EJBCA 3.9 the External RA is finally getting some long waited improvements.
The CA component will now run as a service in EJBCA. This means that you do most of the configuration in the admin-GUI of EJBCA and that it runs very nicely in a CA cluster. You can also configure multiple external RAs, as many as you need.
Setting up a cluster of external RAs is now very simple, if you have a cluster of two external RAs simply configure two external RA services in EJBCA and you're done. No need to use complicated database clusters etc on the external RAs, each external RA node can be simple and stand-alone.
Installation of the external RA is also much much simpler now. Configure the path to the external RA package in EJBCA and the needed CA service is automatically pulled into EJBCA so it is available to be configured in the Admin-GUI. The only thing that needs some though is the configuration of datasources in your application server.
To summarize:
- Easier to install and configure
- Runs nice in a CA cluster
- Runs nice against multiple external RAs
As an added bonus, it's also now almost trivial for developers to implement new types of external RA messages. Internally it uses java reflection, so all you have to do is implement the message classes and handlers. The rest is handled automatically.
The CA component will now run as a service in EJBCA. This means that you do most of the configuration in the admin-GUI of EJBCA and that it runs very nicely in a CA cluster. You can also configure multiple external RAs, as many as you need.
Setting up a cluster of external RAs is now very simple, if you have a cluster of two external RAs simply configure two external RA services in EJBCA and you're done. No need to use complicated database clusters etc on the external RAs, each external RA node can be simple and stand-alone.
Installation of the external RA is also much much simpler now. Configure the path to the external RA package in EJBCA and the needed CA service is automatically pulled into EJBCA so it is available to be configured in the Admin-GUI. The only thing that needs some though is the configuration of datasources in your application server.
To summarize:
- Easier to install and configure
- Runs nice in a CA cluster
- Runs nice against multiple external RAs
As an added bonus, it's also now almost trivial for developers to implement new types of external RA messages. Internally it uses java reflection, so all you have to do is implement the message classes and handlers. The rest is handled automatically.
Saturday, March 28, 2009
EJBCA 3.8.2 released
"This is a minor release adding improvements and bugfixes
- Add street and pseudonym DN attributes.
- OCSP improvements, RFC 5019, nextUpdate, support for requests using GET, improved configuration and error handling.
- Correct coding of optional Issuing Distribution Point in CRLs.
- Possible to publish userPassword in LDAP.
- A few minor fixes."
Check out the change-log for all the details.
A pretty cool feature that hides behind the "RFC 5019" improvement is that you can now cache OCSP responses. If you use HTTP GET you will be able to use simple network components like a HTTP/1.1 cache (Apache httpd config included in the docs) for caching and load-balancing between your responders. I'd love to see someone try this out on a massive scale and report back to me with some statistics.. =)
- Add street and pseudonym DN attributes.
- OCSP improvements, RFC 5019, nextUpdate, support for requests using GET, improved configuration and error handling.
- Correct coding of optional Issuing Distribution Point in CRLs.
- Possible to publish userPassword in LDAP.
- A few minor fixes."
Check out the change-log for all the details.
A pretty cool feature that hides behind the "RFC 5019" improvement is that you can now cache OCSP responses. If you use HTTP GET you will be able to use simple network components like a HTTP/1.1 cache (Apache httpd config included in the docs) for caching and load-balancing between your responders. I'd love to see someone try this out on a massive scale and report back to me with some statistics.. =)
Tuesday, February 3, 2009
Using smart card browser authentication in Ubuntu
To use smart card authentication in Firefox on Ubuntu 8.10 you have to install pcscd, a working card reader driver (if the built in ccid does not work for you) and a pkcs#11 module.
This example works for Ubuntu 8.10. In my case I have an OmniKey CardMan 3021 USB card reader and a smart card with 2048 bit RSA keys. To be able to use 2048 bit keys using the OmniKey reader I have to use their driver.
- Download driver from omnikey.com and put in /tmp
# sudo su -
# apt-get install pcscd
# cd /tmp
# tar -zxvf ifdokccid_lnx_x64-3.5.1.tar.gz
# cd /usr/lib/pcsc/drivers
# cp -r /tmp/ifdokccid_lnx_x64-3.5.1/ifdokccid_lnx_x64-3.5.1.bundle .
# rm -rf ifd-ccid.bundle/
# /etc/init.d/pcscd restart
# apt-get install mozilla-opensc
Finally open pkcs11.html in Firefox and click "Install opensc in linux".
--- pkcs11.html ---
<HTML>
<HEAD>
<TITLE>opensc</TITLE>
</HEAD>
<BODY>
<SCRIPT>
PKCS11_PUBLIC_READ_CERT = 0x1<<28;
function doInstallPkcs11Windows()
{
pkcs11.addmodule("opensc", "opensc-pkcs11.dll", PKCS11_PUBLIC_READ_CERT, 0);
}
function doInstallPkcs11Linux()
{
pkcs11.addmodule("opensc", "opensc-pkcs11.so", PKCS11_PUBLIC_READ_CERT, 0);
}
function doUninstallPkcs11()
{
pkcs11.deletemodule("opensc");
}
</SCRIPT>
<a href=javascript:doInstallPkcs11Linux();>Install opensc in Linux</a><br>
<a href=javascript:doInstallPkcs11Windows();>Install opensc in Windows</a><br>
<a href=javascript:doUninstallPkcs11();>Uninstall opensc</a><br>
</BODY>
</HTML>
This example works for Ubuntu 8.10. In my case I have an OmniKey CardMan 3021 USB card reader and a smart card with 2048 bit RSA keys. To be able to use 2048 bit keys using the OmniKey reader I have to use their driver.
- Download driver from omnikey.com and put in /tmp
# sudo su -
# apt-get install pcscd
# cd /tmp
# tar -zxvf ifdokccid_lnx_x64-3.5.1.tar.gz
# cd /usr/lib/pcsc/drivers
# cp -r /tmp/ifdokccid_lnx_x64-3.5.1/ifdokccid_lnx_x64-3.5.1.bundle .
# rm -rf ifd-ccid.bundle/
# /etc/init.d/pcscd restart
# apt-get install mozilla-opensc
Finally open pkcs11.html in Firefox and click "Install opensc in linux".
--- pkcs11.html ---
<HTML>
<HEAD>
<TITLE>opensc</TITLE>
</HEAD>
<BODY>
<SCRIPT>
PKCS11_PUBLIC_READ_CERT = 0x1<<28;
function doInstallPkcs11Windows()
{
pkcs11.addmodule("opensc", "opensc-pkcs11.dll", PKCS11_PUBLIC_READ_CERT, 0);
}
function doInstallPkcs11Linux()
{
pkcs11.addmodule("opensc", "opensc-pkcs11.so", PKCS11_PUBLIC_READ_CERT, 0);
}
function doUninstallPkcs11()
{
pkcs11.deletemodule("opensc");
}
</SCRIPT>
<a href=javascript:doInstallPkcs11Linux();>Install opensc in Linux</a><br>
<a href=javascript:doInstallPkcs11Windows();>Install opensc in Windows</a><br>
<a href=javascript:doUninstallPkcs11();>Uninstall opensc</a><br>
</BODY>
</HTML>
Thursday, January 29, 2009
EJBCA 3.8.1 released
This is a minor release, targeted for adding support for JBoss 5 and fixing a mistake that caused install on Glassfish to fail.
It also adds a few minor improvements and bugfixes.
- Add support for JBoss 5.
- Fix support for Glassfish caused by a forgotten commit in 3.8.0.
- Improve support for Weblogic 10.3.
- Fix support for IPv6 subject alternative names.
- A few minor CMP, OCSP and CVC fixes.
See the full changelog at ejbca.org for details.
It also adds a few minor improvements and bugfixes.
- Add support for JBoss 5.
- Fix support for Glassfish caused by a forgotten commit in 3.8.0.
- Improve support for Weblogic 10.3.
- Fix support for IPv6 subject alternative names.
- A few minor CMP, OCSP and CVC fixes.
See the full changelog at ejbca.org for details.
Subscribe to:
Posts (Atom)