16 March 2009
It’s not often that you’ll be creating your own X.509 certificates for a web server, since any certificates that you create (self-signed or signed by your own CA) will not be trusted by most browsers (IE, Firefox, etc.) since they were not signed by one of the many Certificate Authorities (CAs) that have been automatically trusted by the browser. If you do decide to use one of these certificates on your web server, you’ll have to navigate through a Byzantine series of screens to “confirm” that you trust the server’s certificate. (Though this is annoying, it may be ultimately beneficial in today’s era of phishing and other malicious behaviour.)
Continued
27 October 2008
The Bouncy Castle Cryptography Java APIs are an excellent set of APIs that act as a provider for JCE and JCA. Additionally, they take care of the mundane and tedious (some would say overly complicated) details involved in reading and creating the data structures associated with the X.500 and PKCS standards. (The APIs are also available in C#, for .NET developers out there)
One thing they handle well is the concept of certificate extensions. X.509 v3 certificates introduced the concept of these extensions, which are basically additional (potentially optional) fields containing information not contained in the older original X.509 specifications. Each extension is specified by an OID (Object Identifier); a good list of these extensions is available.
While it’s easy to read these extensions from an existing X.509 v3 certificate using the Bouncy Castle APIs it is a bit more involved to read these extensions from a Certificate Signing Request, or CSR; this is the data structure that is sent to a CA to request a certificate. The CA then reads the data from this and creates a signed certificate issued to the requester. In this guide I’ll present a brief way to extract X.509 extensions request from a CSR so that they may be included in the resulting issued certificate.
Continued