Within a day SignServer, the enterprise digital signature server, released two new versions, 3.1.5 and 3.2.0. The most interesting of course, being SignServer 3.2.0.
To download, visit SignServer.org
Release notes for SignServer 3.2.0.
Release notes for SignServer 3.1.5.
SignServer supports many different signature formats such as XML, PDF, ODF, OOXML, CMS and MRTD (ePassport).
Friday, July 1, 2011
Wednesday, June 15, 2011
New EJBCA + SignServer LiveCD available
I have just created a new EJBCA LiveCD with EJBCA 4.0.3 and SignServer 3.2-svn.
On this LiveCD there is the latest release of OpenSC (0.12.1). Smart card enrollment and authentication has been tested with both Feitian and Aventra smart cards.
The LiveCD is available to download from the EJBCA web site.
Regards,
Tomas
On this LiveCD there is the latest release of OpenSC (0.12.1). Smart card enrollment and authentication has been tested with both Feitian and Aventra smart cards.
The LiveCD is available to download from the EJBCA web site.
Regards,
Tomas
Sunday, June 12, 2011
CMP for OpenSSL, new tool in the PKI professionals toolbox
I was hinted by a user of EJBCA at CMP for OpenSSL. It's a nice new open source toolkit, both development API and client tools.
The cmpclient works perfect with EJBCA CMP in RA mode. I have documented how it works, with a sample command in the EJBCA Admin Guide.
All in all, good signs for CMP I think.
The cmpclient works perfect with EJBCA CMP in RA mode. I have documented how it works, with a sample command in the EJBCA Admin Guide.
All in all, good signs for CMP I think.
Tuesday, June 7, 2011
CMP interoperability
I have been making more tests, and some improvements, on CMP interoperability for EJBCA.
You can see some of the results here.
In short, CMP mostly seems to work purely technical. What is cumbersome with the CMP protocol is that there are so many options. For a CA to say that you support CMP does not mean much. You must explicitly say which specific CMP work-flows, with technical details that you support. Otherwise it does not mean much. For example, how are enrolling clients authenticated? Common options include:
The options virtually have no limits.
As you see it is a very large work to implement all options. The rule we use is that we implement options that we actually see usage of, which of course means that we need to improve continuously. I think it is the only way to work efficiently however, not to implement functions that will never be used. The downside is of course that someone can come along and find our implementation not supporting their use-case. Usually new things can be implemented with rather short investment.
You can see some of the results here.
In short, CMP mostly seems to work purely technical. What is cumbersome with the CMP protocol is that there are so many options. For a CA to say that you support CMP does not mean much. You must explicitly say which specific CMP work-flows, with technical details that you support. Otherwise it does not mean much. For example, how are enrolling clients authenticated? Common options include:
- Shared secret used for Password based MAC, where keyId is username (specified in profile in RFC). Shared secret must be in clear text in CA database, which is a down-side. Pre-registration of end entities needed.
- Shared secret with one-time password in regToken control. Pre-registration of end entities needed.
- Digital signature protected request message, where digital signature is based on an out-of-band issued certificate, possibly from another CA. Pre-registration of end entities needed.
- RA type application with Password based HMAC, where RA specifies the certificate contents in the request, and authenticated using a shared secret. No pre-registration of end entities needed.
- RA type application with digital signature authentication. No pre-registration of end entities needed.
- Etc...
The options virtually have no limits.
As you see it is a very large work to implement all options. The rule we use is that we implement options that we actually see usage of, which of course means that we need to improve continuously. I think it is the only way to work efficiently however, not to implement functions that will never be used. The downside is of course that someone can come along and find our implementation not supporting their use-case. Usually new things can be implemented with rather short investment.
Thursday, June 2, 2011
EJBCA 4.0.3 released
On the 1st of June we released EJBCA 4.0.3. This is a minor release with only a few fixes. In all 5 issues have been resolved.
Noteworthy changes:
Read the full Changelog for details, https://jira.primekey.se/secure/IssueNavigator.jspa?reset=true&pid=10000&fixfor=10443.
Regards,
The PrimeKey EJBCA Team
Noteworthy changes:
- Improved CMP interoperability, with minor improvement and bugfixes.
- Fixed a bug that made it impossible to delete end entity profile on certain databases, in particular hsql (test database).
Read the full Changelog for details, https://jira.primekey.se/secure/IssueNavigator.jspa?reset=true&pid=10000&fixfor=10443.
Regards,
The PrimeKey EJBCA Team
Sunday, May 22, 2011
EJBCA 4.0.2 released
We are proud to release EJBCA 4.0.2. This release brings many optimizations and improvements to EJBCA 4.0. We regard this as the best version of EJBCA to date, setting new performance records as well as improving on the already extensive feature set. A thorough time for QA also assures that this should be one of the most stable releases in production for the coming months.
In all 44 issues have been resolved.
Noteworthy changes:
The ISO8601 date format (yyyy-MM-dd HH:mm:ssZZ) is used in the Admin GUI and EJBCA WS interface,
so clients no longer have to be aware of in what time zone the CA servers are located.
The old format (in US Locale) will still work for incoming requests in the WS, but any returned
UserDataVOWS containing custom start and end date will use the new format.
Read the full Changelog for details.
Regards,
The PrimeKey EJBCA Team
In all 44 issues have been resolved.
Noteworthy changes:
- Internal optimizations makes this the fastest version of EJBCA ever, capable of issuing > 400 certificates/second (depending on configuration).
- Certificate enrollment now works also with Safari and Chrome browsers and Android 2.3.4.
- Support for PrivateKeyUsagePeriod certificate extension.
- Fixed a time zone bug issuing CVC certificates where the date was encoded using local timezone instead of GMT in certificates.
- More admin console and public web improvements from David Carella of Linagora.
- Now uses ISO8601 date format consistently when entering dates in admin console.
- Automatic generation of Norwegian UNID numbers from CMP requests.
- Many small bug fixes and improvements.
The ISO8601 date format (yyyy-MM-dd HH:mm:ssZZ) is used in the Admin GUI and EJBCA WS interface,
so clients no longer have to be aware of in what time zone the CA servers are located.
The old format (in US Locale) will still work for incoming requests in the WS, but any returned
UserDataVOWS containing custom start and end date will use the new format.
Read the full Changelog for details.
Regards,
The PrimeKey EJBCA Team
Tuesday, May 3, 2011
EJCBA 3.11.2 released
The PrimeKey EJBCA team is happy to announce that EJBCA 3.11.2 has been released! This is a maintenance release – 23 issues have been resolved. The most noteworthy changes can be seen below.
EJBCA 3.11.2 is a maintenance release in the 3.11 branch of EJBCA. The main release branch of EJBCA is the 4.0 branch, where 4.0.1 has been released, and 4.0.2 is upcoming.
EJBCA 3.11.2 Release Notes
Improvements and new features:
Development continues beyond this version and all requests from the community are scheduled for EJBCA 3.11.3 or later releases.
More information is available at the project web site and the complete changelog can be viewed in the issue tracker.
EJBCA 3.11.2 is a maintenance release in the 3.11 branch of EJBCA. The main release branch of EJBCA is the 4.0 branch, where 4.0.1 has been released, and 4.0.2 is upcoming.
EJBCA 3.11.2 Release Notes
Improvements and new features:
- Increased algorithm support on PKCS11 HSMs.
- Added a webservice based RA written by Daniel Horn.
- It is now possible to disable the command line interface.
- There are new commands to import CRLs and certificates which are useful when migrating to EJBCA.
- Documented the fact that External OCSP does not run on JBoss 5.x.
- Added GlassFish database schema for Oracle.
- Added a webservice call for retrieving CA path.
- Removed some unelegant error messages from the GUI.
- Removed a bug that sometimes caused a day longer validity of certificates due to day light savings.
- Fixed bug which prevented revokation after upgrading from EJBCA 3.4.x.
- Fixed a bug causing some information to not be logged during WS calls.
- Fixed a bug preventing revoked certificates to be republished to the VA server.
- Republish button now works with special characters and without certificate request history.
Development continues beyond this version and all requests from the community are scheduled for EJBCA 3.11.3 or later releases.
More information is available at the project web site and the complete changelog can be viewed in the issue tracker.
Subscribe to:
Comments (Atom)