Certificate Formats - X.509, DER and PEM Certificate standard and file encodings seem to be confusing. I wrote down some notes about:
X.509 Certificate Standard X.509 is an international standard for what should be included in a digital certificate. Here is the definition from webpedia.com: A widely used standard for defining digital certificates. X.509 (Version 1) was first issued in 1988 as a part of the ITU X.500 Directory Services standard. When X.509 was revised in 1993, two more fields were added resulting in the Version 2 format. These two additional fields support directory access control. X.509 Version 3 defines the format for certificate extensions used to store additional information regarding the certificate holder and to define certificate usage. Collectively, the term X.509 refers to the latest published version, unless the version number is stated. X.509 is published as ITU recommendation ITU-T X.509 (formerly CCITT X.509) and ISO/IEC/ITU 9594-8 which defines a standard certificate format for public key certificates and certification validation. With minor differences in dates and titles, these publications provide identical text in the defining of public-key and attribute certificates. My understanding of X.509 is that a certificate is required to have the following information:
The content structure of a Version 3 X.509 certificate should look like this: Certificate: Data: Version: 3 (0x2) Serial Number: 1185572113 (0x46aa6511) Signature Algorithm: dsaWithSHA1 Issuer: C=CA, ST=Herong State, L=Herong City, ... Validity Not Before: Apr 1 21:35:13 2007 GMT Not After : Jun 30 21:35:13 2007 GMT Subject: C=CA, ST=Herong State, L=Herong City, ... Subject Public Key Info: Public Key Algorithm: dsaEncryption DSA Public Key: pub: 00:b0:61:2b:c1:88:0e:19:66:58:37:b5:... ... P: 00:fd:7f:53:81:1d:75:12:29:52:df:4a:... ... Q: 00:97:60:50:8f:15:23:0b:cc:b2:92:b9:... ... G: 00:f7:e1:a0:85:d6:9b:3d:de:cb:bc:ab:... ... Signature Algorithm: dsaWithSHA1 30:2c:02:14:6c:21:f3:43:b5:4f:d5:3d:2e:23:89:45:0... ... X.509 define how a certificate contents should be written. It does define how certificate contents should be encoded to store in files. Two commonly used encoding schemas are used to store X.509 certificates in files, DER and PEM, as described in next sections. PEM (Privacy Enhanced Mail) Encoding The most commonly used encoding schema for X.509 certificate files is the PEM (Privacy Enhanced Mail) encoding. Here is the definition of PEM on wikipedia.com: "Privacy Enhanced Mail (PEM), is an early IETF proposal for securing email using public key cryptography. Although PEM became an IETF proposed standard it was never widely deployed or used. The full specification of PEM is in RFC 1421. But the idea of PEM encoding on X.509 certificates is very simple:
Here is a structural sample of a PEM encoded X.509 certificate: -----BEGIN CERTIFICATE----- MIIDODCCAvagAwIBAgIERqplETALBgcqhkjOOAQDBQAwfzELMAkGA1UE... ... Cgfs2kXj/IQCFDC5GT5IrLTIFxAyPUo1tJo2DPkK -----END CERTIFICATE----- PEM encoded certificate files are supported by almost all applications. "OpenSSL" and "keytool" support PEM encoded certificate files with no problem. See other sections below for test notes. (Continued on next part...)
Certificate Formats - X.509, DER and PEM (Continued from previous part...) DER (Distinguished Encoding Rules) Encoding DER (Distinguished Encoding Rules) is another popular encoding used to store X.509 certificate files. Here is how wikipedia.com describes PEM: DER or Distinguished Encoding Rules is a method for encoding a data object, such as an X.509 certificate, to be digitally signed or to have its signature verified. The Distinguished Encoding Rules of ASN.1 is an International Standard drawn from the constraints placed on BER encodings by X.509. DER encodings are valid BER encodings. DER is the same thing as BER with all but one sender's options removed. For example, in BER a boolean value of true can be encoded in 255 ways, while in DER there is only one way to encode a boolean value of true. The full specification of DER is in RFC 1421. X.509 certificate files encode in DER are binary files, which can not be view with text editors. DER encoded certificate files are supported by almost all applications. "OpenSSL" and "keytool" support DER encoded certificate files with no problem. See other sections below for test notes. "keytool" Exporting Certificates in DER and PEM My first test was about "keytool" exporting certificates in DER and PEM encodings. This was done as:
The test session was recorded below: >keytool -genkeypair -keysize 1024 -alias herong_key -keypass keypass -keystore herong.jks -storepass jkspass What is your first and last name? [Unknown]: Herong Yang What is the name of your organizational unit? [Unknown]: Herong Unit What is the name of your organization? [Unknown]: Herong Company What is the name of your City or Locality? [Unknown]: Herong City What is the name of your State or Province? [Unknown]: Herong State What is the two-letter country code for this unit? [Unknown]: CA Is CN=Herong Yang, OU=Herong Unit, O=Herong Company, L=Herong City, ST=Herong State, C=CA correct? [no]: yes >keytool -exportcert -alias herong_key -keypass keypass -keystore herong.jks -storepass jkspass -file keytool_crt.der Certificate stored in file <keytool_crt.der> >keytool -exportcert -alias herong_key -keypass keypass -keystore herong.jks -storepass jkspass -rfc -file keytool_crt.pem Certificate stored in file <keytool_crt.pem> Not that "keytool -exportcert" command applies DER encoding by default. The "-rfc" option is to change it to PEM (RFC 1421) encoding. Now I got one certificate generated by "keytool" and stored in two encoding files: keytool_crt.der and keytool_crt.pem. How can I verify that they are really using the correct encoding schemas? I used "OpenSSL" to try to view them as described in the next section. "OpenSSL" Verifying "keytool" Certificates One way to verify if "keytool" did export my certificate using DER and PEM encoding correctly is to use "OpenSSL" view the encoded certificate files. To do this, I used the "openssl x509" command to view keytool_crt.der and keytool_crt.pem: >openssl x509 -in keytool_crt.pem -inform pem -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 1185636568 (0x46ab60d8) Signature Algorithm: dsaWithSHA1 Issuer: C=CA, ST=Herong State, L=Herong City, ... ... >openssl x509 -in keytool_crt.der -inform der -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 1185636568 (0x46ab60d8) Signature Algorithm: dsaWithSHA1 Issuer: C=CA, ST=Herong State, L=Herong City, ... O=Herong Company, OU=Heron ... What I learned so far:
"OpenSSL" Generating Certificates in DER and PEM After tested how "keytool" can be used to export certificates in DER and PEM encodings, I decided to try with "OpenSSL" to see if it can generate certificates in the same encodings or not. What I did was to:
The test session was recorded below: >openssl genrsa -out herong.key -des 1024 Loading 'screen' into random state - done Generating RSA private key, 1024 bit long modulus .........................++++++ ...................++++++ e is 65537 (0x10001) Enter pass phrase for herong.key: keypass Verifying - Enter pass phrase for herong.key: keypass >openssl req -new -x509 -key herong.key -out openssl_crt.pem -outform pem -config openssl.cnf Enter pass phrase for herong.key: keypass You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [CA]: State or Province Name (full name) [HY State]: Locality Name (eg, city) [HY City]: Organization Name (eg, company) [HY Company]: Organizational Unit Name (eg, section) [HY Unit]: Common Name (eg, YOUR name) [Herong Yang]: Email Address [herongyang.com]: >openssl x509 -in openssl_crt.pem -inform pem -out openssl_crt.der -outform der Now I got one certificate generated by "OpenSSL" and stored in two encoding files: openssl_crt.der and openssl_crt.pem. How can I verify that they are really using the correct encoding schemas? I used "keytool" to try to import them as described in the next section. "keytool" Viewing "OpenSSL" Certificates One way to verify the certificate generated by "OpenSSL" and stored in PEM and DER encodings is to view it with the "keytool -printcert" command: >keytool -printcert -file openssl_crt.pem Owner: EMAILADDRESS=herongyang.com, CN=Herong Yang, OU=HY Unit, ... Issuer: EMAILADDRESS=herongyang.com, CN=Herong Yang, OU=HY Unit, ... Serial number: 0 Valid from: Sun Apr 1 13:02:22 EDT 2007 until: ... Certificate fingerprints: MD5: BF:B8:3A:19:E5:05:CE:CA:8C:F7:05:FA:FE:51:A6:EC SHA1: F7:C7:2A:57:73:5E:CE:E5:73:09:13:35:FB:91:CF:27:... Signature algorithm name: MD5withRSA Version: 3 Extensions: ... >keytool -printcert -file openssl_crt.der Owner: EMAILADDRESS=herongyang.com, CN=Herong Yang, OU=HY Unit, ... Issuer: EMAILADDRESS=herongyang.com, CN=Herong Yang, OU=HY Unit, ... Serial number: 0 Valid from: Sun Apr 1 13:02:22 EDT 2007 until: ... Certificate fingerprints: MD5: BF:B8:3A:19:E5:05:CE:CA:8C:F7:05:FA:FE:51:A6:EC SHA1: F7:C7:2A:57:73:5E:CE:E5:73:09:13:35:FB:91:CF:27:... Signature algorithm name: MD5withRSA Version: 3 Extensions: ... What I learned so far:
"keytool" Importing "OpenSSL" Certificates I also tried to import the certificate generated by "OpenSSL" into "keytoo" keystore files. The "keytool -importcert" command had no trouble reading the certificate in both PEM and DER encodings. My command session is recorded here: >keytool -importcert -file openssl_crt.pem -keystore herong.jks -storepass jkspass -alias openssl_crt_pem -keypass keypass Owner: EMAILADDRESS=herongyang.com, CN=Herong Yang, OU=HY Unit, ... Issuer: EMAILADDRESS=herongyang.com, CN=Herong Yang, OU=HY Unit, ... Serial number: 0 Valid from: Sun Apr 1 13:02:22 EDT 2007 until: ... Certificate fingerprints: MD5: BF:B8:3A:19:E5:05:CE:CA:8C:F7:05:FA:FE:51:A6:EC SHA1: F7:C7:2A:57:73:5E:CE:E5:73:09:13:35:FB:91:CF:27:... Signature algorithm name: MD5withRSA Version: 3 Extensions: ... Trust this certificate? [no]: yes Certificate was added to keystore >keytool -importcert -file openssl_crt.der -keystore herong.jks -storepass jkspass -alias openssl_crt_der -keypass keypass Certificate already exists in keystore under alias <openssl_crt_pem> Do you still want to add it? [no]: yes Certificate was added to keystore >keytool -list -keystore herong.jks -store pass jkspass Keystore type: JKS Keystore provider: SUN Your keystore contains 3 entries openssl_crt_der, Apr 1, 2007, trustedCertEntry, Certificate fingerprint (MD5): BF:B8:3A:19:E5:05:CE:CA:8C:F7:05:... openssl_crt_pem, Apr 1, 2007, trustedCertEntry, Certificate fingerprint (MD5): BF:B8:3A:19:E5:05:CE:CA:8C:F7:05:... herong_key, Apr 1, 2007, PrivateKeyEntry, Certificate fingerprint (MD5): 5B:44:F1:D7:3D:9F:9E:15:5B:D1:25:... Wonderful! There was no trouble at for "keytool" to import my self-signed certificate generated by "OpenSSL" into the keystore file. Conclusion
|