Dear Martin, In your last mail, u told that current release of OpenXPKI contains the necessary code to be integrated with HSM. So Kindly provide me the COMPLETE method of integration of HSM's with OpenXPKI ?
Regards Mary Peterson University of Essex ________________________________ From: Martin Bartosch <[email protected]> To: [email protected] Sent: Tue, November 17, 2009 4:34:33 PM Subject: [OpenXPKI-users] OpenXPKI success story revisited (Re: OpenXPKI End to End Features) Hi Mary, > I have installed EJBCA on Fedora Core 10 in 2 days and successfully > tested it with nCipher and PrimeCard HSM's. Now i have turned hands > on with OpenXPKI. There is a success story written at www.openxpki.org > > "The first production deployment of OpenXPKI was performed on > Friday, 2007-01-26 by Cynops GmbH for a customer. > > In the current implementation phase OpenXPKI is solely used for one > single purpose - it implements a self-service application for > SmartCard personalization " > > > I have consulted the forums but did not find something regarding > it . I have also played with OpenXPKI Live CD, but found nothing to > integrate with HSM's. Was it done open source or specifcally for > some sort of paid customer ? Are the features listed of Open Source > OpenXPKI or PAID OpenXPKI ? let me answer your questions first briefly, you find more detailed information below. The OpenXPKI Live CD does not include the necessary nCipher driver software (which cannot be distributed due to license issues). It does, however, include the necessary application code to use an installed HSM. So if you manage to install the drivers provided by nCipher in the live environment you should be able to get it to work. Note that the CD is based on a quite old snashot of OpenXPKI and needs to be updated. * Update on the success story I was the person who wrote this success story. The initial installation was done to provide a self-service personalization web interface to users of the company. As I wrote, this solution has been in production since January 2007. Naturally we had to do customizing for the company IT environment, so we started with the official repository and locally forked a customer- specific branch in our local version control system (we are using git here, btw). This customer specific branch was modified to reflect company branding (e. g. web site design) and some specific modifications necessary for integration with existing IT systems (LDAP, ActiveDirectory etc). Most of the development for the customer was backported to the official release and is available as OpenSource in the public repository. Public changes from the repository are merged into our custom branch which keeps the customized version up-to-date. In May 2009 we finally got rid of the old OpenCA installation that was running in parallel to OpenXPKI. The main motivation was that we had to perform a Root CA rollover which would have been a pain to perform in OpenCA. We did this by adding another PKI realm to the configuration (so we now have a 'User CA' and a 'Server CA' realm in our OpenXPKI instance). The old issuing CA and all certificates ever issued by OpenCA were migrated into the newly created OpenXPKI 'Server CA' realm using a migration script that created the necessary certificate and workflow entries for all existing certificates. Migrating the old certificates was necessary because of the following reasons: - registration officers needed to be able to see and reference older certificates - revocation lists for old certificate needs to be produced - revocation of valid certificates issued under OpenCA had to be possible even after the migration - automatic renewal of certificates via SCEP (CertNanny) had to be possible even after the CA rollover After migrating the old certificates, the new Root CA and Issuing CAs were configured in OpenXPKI which now automatically handles the issuance of certificates under the new CA and keeps issuing CRLs for existing certificates that were issued under the OpenCA installation. The SCEP server of OpenXPKI is now also able to handle fully automatic renewal based on the existing certificate (which may be a migrated one from OpenCA). All PKI realms on the OpenXPKI installation are using the unmodified nCipher driver that is included in the public OpenXPKI repository. Our issuing CAs use the HSMs for protecting all infrastructure keys (e. g. CA keys) and also sensitive information used by the PKI application. The latter is implemented via the "PasswordSafe" Workflow that is shipped with OpenXPKI. It uses an encryption certificate and a private key that is protected by the HSM. The HSMs are used in an "always active" scenario: the HSM keys are enabled by the operator and even after he logs out the keys stay available until explicitly deactivated or system reboot. HSM key activation is done remotely via the "Remote Operator Card Set" feature of nCipher nShield. In the past months I have been heavily working on improving the SmartCard personalization process which has been completely reimplemented (the old implementation remains available as a separate workflow). It now supports key backup for encryption keys (an necessary precondition if SmartCards shall be used for data encryption, e. g. for emails). The personalization process automatically reinstalls the existing encryption certificate if it was deleted from the card or if the card was replaced. Unfortunately this new SmartCard personalization currently cannot easily be backported to the public repository because it uses a proprietary interface to the SmartCards. But I will try to find a solution for this in the next year. * Current issues and next steps The OpenXPKI core has proven to be quite stable for us in the past months. The workflow engine and the crypto backend basically work fine. There are minor issues, but we can live with them. However, there are some portions of the application which need attention. - The web frontend badly needs to be rewritten. My current plan is to start development on an alternative web frontend that uses a real MVC framework and AJAX to provide increased stability and extensibility. It will possibly even contain or integrate a CMS to allow embedding PKI functionality in easily customizable web pages. I will start on this by first implementing one single part of the web interface (the SmartCard personalization web frontend). Once this has been done, we can work on extending functionality to cover the missing topics. I will port this web frontend to the public repository once it is usable. - when using HSMs it sometimes happens that a forked workflow dies during execution. This results 'dangling' workflows that keep waiting for deceased children. This could be addressed e. g. via a reaper process which triggers stalled workflows and that handles notification of parent workflows. - the documentation of OpenXPKI is still far from being usable, this needs to be extended to make the system usable for people new to the project Cheers Martin
------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev
_______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
