The CertificateFactory Class Certificates

Running this program would produce the following output: piccolo java −classpath ...... javasec.samples.ch09.PrintCert Read in the following certificate: Certificate for: CN=Scott Oaks, OU=SMCC, O=Sun, L=NY, ST=NY, C=US Certificate issued by: CN=Thawte Test CA Root, OU=TEST TEST TEST, O=Thawte Certification, ST=FOR TESTING PURPOSES ONLY, C=ZA The certificate is valid from Wed Apr 19 14:01:51 EDT 2000 to Sat May 20 14:01:51 EDT 2000 Certificate SN 6042116 Generated with MD5withRSA

9.4.4 Advanced X509Certificate Methods

There are a number of other methods of the X509Certificate class. For the purposes of this book, these methods are not generally useful; they enable you to perform more introspection on the certificate itself. Well list these methods here simply as a matter of record. public abstract byte[] getTBSCertificate Get the DER−encoded TBS certificate. The TBS certificate is the body of the actual certificate; it contains all the naming and key information held in the certificate. The only information in the actual certificate that is not held in the TBS certificate is the name of the algorithm used to sign the certificate and the signature itself. The TBS certificate is used as the input data to the signature algorithm when the certificate is signed or verified. public abstract byte[] getSignature Get the raw signature bytes of the certificate. These bytes could be used to verify the signature explicitly e.g., using the methods well describe in Chapter 12 instead of relying upon the verify method to do so. public abstract String getSigAlgName Return the name of the algorithm that was used to sign the certificate. For the Sun implementation, this will always be SHA1withDSA . public String getSigAlgOID Return the OID of the signature algorithm used to produce the certificate. public abstract byte[] getSigAlgParams Return the DER−encoded parameters that were used to generate the signature. In general, this will return null since the parameters are usually specified by the certificate authoritys public key. public abstract byte[] getIssuerUniqueID Return the unique identifier for the issuer of the certificate. The presence of a unique identifier for each issuer allows the names to be reused, although in general it is recommended that certificates not make use of the unique identifier. Chapter 9. Keys and Certificates public abstract byte[] getSubjectUniqueID Return the unique identifier for the subject of the certificate again, this is unused in general. public abstract BitSet getKeyUsage Return the key usage extension, which defines the purpose of the key: the key may be used for digital signing, nonrepudiation, key encipherment, data encipherment, key agreement, certificate signing, and more. The key usage is an extension to the X509 specification and need not be present in all X509 certificates. public abstract int getBasicConstraints An X509 certificate may contain an optional extension that identifies whether the subject of the certificate is a certificate authority. If the subject is a CA, this extension returns the number of certificates that may follow this certificate in a certification chain.

9.4.5 Revoked Certificates

Occasionally, a certificate authority needs to revoke a certificate it has issued −− perhaps the certificate was issued under false pretenses or maybe the user of the certificate has engaged in illegal conduct using the certificate. Under circumstances such as these, the expiration date attached to the certificate is insufficient protection; the certificate must be immediately invalidated. This invalidation occurs as the result of a CRL −− a certificate revocation list. Certificate authorities are responsible for issuing certificate revocation lists that contain predictably a list of certificates the authority has revoked. Validators of certificates are required to consult this list before accepting the validity of a certificate. Unfortunately, the means by which an authority issues a CRL is one of those areas that is in flux, and while the interfaces to support revoked certificates have been established, they are not completely integrated into most certificate systems. In particular, the validate method of the Certificate class doesnt automatically consult any CRL. The CRL itself is typically obtained in an out−of−band fashion just as the certificates of the authority were obtained; once you have a CRL, you can check to see if a particular certificate in which youre interested is on the list. While the notion of revoked certificates in not necessarily specific to an X509 certificate, the Java implementation is. Revoked certificates themselves are represented by the X509CRLEntry class java.security.cert.X509CRLEntry : public abstract class X509CRLEntry implements X509Extension The methods of this class are simple and are based upon the fields present in a revoked X509 certificate: public abstract BigInteger getSerialNumber Return the serial number of the revoked certificate. public abstract Date getRevocationDate Return the date on which the certificate was revoked. public abstract boolean hasExtensions Indicate whether the implementation of the class has any X509 extensions.