Posts

Showing posts with the label PKI

Java SE Disables MD2 Algorithm in Certification Path Building and Validation

The MD2 Message-Digest Algorithm is no longer considered secure [1][2][3][4], Java SE disables MD2 algorithm in certification path building and validation from Java SE 1.6.0_17 (6u17) [JavaSE 6u17] and Java SE 1.5.0_22 (5u22) [JavaSE 5u22]. However, even as of 2011, the MD2 algorithm remains in use in Public Key Infrastructures (PKI) as part of certificates generated with MD2 and RSA. It is recommended to request or renew a new certificate with stronger cryptographic algorithm from the Certificate Authority (CA). [1]: Søren S. Thomsen (2008). An improved preimage attack on MD2 [2]: Knudsen, L., Mathiassen, J., Muller, F., and Thomsen, S., "Cryptanalysis of MD2", Journal of Cryptology, 23(1):72-90, 2010. [3]: CVE-2009-2409 [4]: S. Turner, L. Chen, "MD2 to Historic Status", RFC 6149, March 2011 [JavaSE 6u17]: Java SE 6 update 17 [JavaSE 5u22]: Java SE 1.5.0 update 22

Enable OCSP checking

If a certificate is issued with a authority information access extension which indicates the OCSP access method and location, one can enable the default implementation of OCSP checker during building or validating a certification path. Maybe you need to check your certificate firstly, in the purpose of making sure it includes a OCSP authority information access extension: #${JAVA_HOME}/bin/keytool -printcert -v -file target.cert You are expected to see similar lines in the output: #3: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false AuthorityInfoAccess [ [accessMethod: 1.3.6.1.5.5.7.48.1 accessLocation: URIName: http://onsite-ocsp.verisign.com] ] In the above output, "http://onsite-ocsp.verisign.com" indicates the location of the OCSP service. If you find one of similar authority information access extension in your certificate path, you need to enable OCSP checker. For Sun PKIX implementation, OCSP checking is not enabled by default for compatibility, note that ...

JSSE Troubleshooting: Certificates Order in TLS Handshaking

Issue: Failed with a exception: java.security.cert.CertPathValidatorException: subject/issuer name chaining check failed. Example: Test case: 1 // 2 // JSSE Troubleshooting: Disordered Certificate List in TLS Handshaking 3 // 4 import java.net.*; 5 6 public class DisorderedCertificateList { 7 public static void main(String[] Arguments) throws Exception { 8 URL url = new URL("https://myservice.example.com/"); 9 URLConnection connection = url.openConnection(); 10 11 connection.getInputStream().close(); 12 } 13 } Test environment: The HTTPS server, myservice.example.com, is configurated with a certificate path that the certificates in the path is out of order. For example, the expected certificate path is server_certificate -> intermediate ca -> seld-signed root ca. However, the certificate path is configurated as server_certificate -> seld-signed root ca -> intermediate ca. Test Result: Exception in ...

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 ke...