Understanding Self-Issued Certificate

Certificate Types

RFC5280 categorize certificate into two classes: CA certificates and end entity certificates, and CA certificates are divided into three classes: cross-certificates, self-issued certificates, and self-signed certificates.
certificate +- CA certificate
+- cross-certificate
+- self-issued certificate
+- self-signed certificat
+- end entity certificate

"Cross-certificates are CA certificates in which the issuer and subject are different entities. Cross-certificates describe a trust relationship between the two CAs." [RFC5280]

"Self-issued certificates are CA certificates in which the issuer and subject are the same entity. Self-issued certificates are generated to support changes in policy or operations." [RFC5280]

"Self-signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate. Self-signed certificates are used to convey a public key for use to begin certification paths." [RFC5280]

Self-signed certificates are speicial slef-issied certificates, so we also can redraw the above tree as:
certificate +- CA certificate
+- cross-certificate
+- self-issued certificate
+- self-signed certificat
+- end entity certificate

Notes of Self-Signed Certificate

1. "The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate." [RFC5280]
2. "When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path." [RFC5280]

Note of Self-Issued Certificate

1. "Name constraints are not applied to self-issued certificates (unless the certificate is the final certificate in the path)." [RFC5280]
2. "However, a CA may issue a certificate to itself to support key rollover or changes in certificate policies. These self-issued certificates are not counted when evaluating path length or name constraints."
3. The pathLenConstraint field of basic constrains extension "gives the maximum number of non-self-issued intermediate certificates that may follow this certificate in a valid certification path."
4. The valude of inhibit anyPolicy extension "indicates the number of additional non-self-issued certificates that may appear in the path before anyPolicy is no longer permitted."

Identify a Self-Issued Certificate

RFC5280 requires that if the names in the issuer and subject field in a certificate match according to the comparison rules of internationalized names in distingushed names, then the certificate is self-issued. Please refer to section 7.1 of [RFC5280] about the comparison rules.
However, RFC3280 does not define the comparison rules, which requires that, "A certificate is self-issued if the DNs that appear in the subject and issuer fields are identical and are not empty." The specificate implies a binary comparison of the subject and issuer fields.
I think a good practice would have the same binary subject and issuer fields while issue a self-issued certificate.

Identify a Self-Signed Certificate

Sounds like a stupid title, just as its name implies, it is self signed, so it is self identifiable, i.e., the public key bound into the certificate could be used to verify the digital signature of the same certificate. Definitely, it's true. OK, we get a bi-steps process:
1. identify that a certificate is a self-issued certificate;
2. Verify the certificate digital signature with the public key bound.
That's a precious process, but not a effective process. Digital signature verify normally hurts a lot of performance, and generally it is not needed to verify the digital signature during build a prospective certification path.

Identify a Self-Signed Certificate Effectively

Self-signed, in another words, the key bound into the certificate is the same as the key used to sign the certificate. Could we identify it by comparing the key bound and the key used to generate the certificate signature? Here comes the authority key identifier extension and the subject key identifier extension, refer to RFC3280/RFC5280 for details.
To facilitate certification path construction, the specification requires that the authority key identifier extension and the subject key identifier extension MUST be appear in all conforming CA certificate. "There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted."
With the help of the two key identifier extensions, we get the following steps:


1. identify that a certificate is a self-issued certificate;
2. for conforming CAs, if the subject key identifier extension appears, but no authority key identifier extension, it is a self-signed certificate; if the both appear, it is a self-signed certificate when the KeyIdentifier is identical.
3. for non-conforming CAs, Verify the certificate digital signature with the public key bound.

Suggested Practices:

1. Always issue certificate with subject key identifier extension and authority key identifier extension.
2. Always include the keyIdentifier field in the authority key identifier extension.
3. Always have the same binary subject and issuer fields while issue a self-issued certificate.
4. Only issue self-issued certificate as CA certificate.
5. For TLS, always send the intermediate self-issued certificate within the response certificate list, otherwise, the recepient normally cannot build a certification path to its trust anchors.

The Problematic Practices Encountered

1. A self-signed CA certificate issues 1+ self-issued end entity certificates.
There is no problem to issue such self-issued End-Entity certificate, but I'm afraid many PKIX libraries would not be able to handle it properly. If your application dependents on third party's PKIX library, and if you have to issue such certificates, please do check the library and make sure it supports such cases.
2. A self-signed CA certificate issues a self-issued certificate as an indirect CRL issuer.
It is special example of self-issed end-entity certificate. Some CRL verification library cannot handle such a indirect CRL issuer correctly, please double check the library to make sure such indirect CRL issuer is supported.
Java SE SDK support the above two problemtic cases at OpenJDK 7 build 60. If you application have to support above cases, you need OpenJDK 7 build 60 at least.

 Linkage to the blog entry at blogs.sun.com

Popular posts from this blog

TLS Server Name Indication Extension and Unrecognized_name

Image
Heavy Pond, Jianfengling National Forest Park, Ledong, Hainan, China It's getting hot that some TLS/HTTPS server failed with "unrecognized_name". For example, the Adobe AIR 3 Code Signing Certificate Problem , the ADT handshake alert , and the jarsigner issue with timestamp.geotrust.com , etc. This entry will discussion some background of the "unrecognized_name" alert, and the TLS Server Name Indication (SNI) extension. Background "Unrecognized_name" is an error alert, define by RFC4366 .  In section 4 of RFC4366 : - "unrecognized_name": this alert is sent by servers that receive a server_name extension request, but do not recognize the server name. This message MAY be fatal. And in section 3.1 of of RFC4366 : If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal). From above sections, we see that "unrecognized...
Read more

Java™ SE 7 Release Security Enhancements - Weak Cryptography Control

Weak cryptographic algorithms can now be disabled in Java SE 7 release. The MD2 Message-Digest Algorithm was disabled by default in Sun PKIX provider and SunJSSE provider. The MD2 algorithm is a cryptographic hash function developed by Ronald Rivest in 1989 , and was published in 1992 as an Informational RFC (RFC 1319) .; RFC 6149 moves RFC 1319/MD2 to historic status, "Since its publication, MD2 has been shown to not be collision-free, albeit successful collision attacks for properly implemented MD2 are not that damaging. Successful pre-image and second pre-image attacks against MD2 have been shown." Although MD2 is no longer considered secure, it remains in use in public key infrastructures as part of certificates generated with MD2 and RSA. An a countermeasure of the vulnerability, Java SE has disabled MD2 algorithm in certification path building and validation. You may wonder, Java SE has disabled MD2 algorithm in certification path building and validation in ...
Read more

JEP 115: AES-GCM CipherSuites in JDK 8

Image
Chengdu, China RFC 5288 describes the use of AES in Galois Counter Mode ( GCM ) (AES-GCM) with various key exchange mechanisms as a cipher suite for TLS. AES-GCM is an authenticated encryption with associated data (AEAD) cipher (as defined in TLS 1.2 ) providing both confidentiality and data origin authentication. Java SE had already defined the AES-GCM interfaces in Java SE 7 .  In the coming Java SE 8, as an implementation of JEP 115 , AES-GCM algorithms is implemented in SunJCE provider, and AES-GCM cipher suites are implemented in SunJSSE provider. The following SSL/TLS AEAD/GCM cipher suites, in preference order, are enabled by default in SunJSSE provider for TLS version 1.2: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (RFC 5289) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_RSA_WITH_AES_256_GCM_SHA384 (RFC 5288) TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_ECDH_RSA_WITH_AES_...
Read more