Invariant Properties

  • rss
  • Home

Introduction to Digital Certificates, Part 3: X509v3

Bear Giles | May 29, 2012

This is part of a series on Digital Certificates.

  • Introduction
  • IDs
  • X.509v3 Certificates
  • Creating Certs with Bouncy Castle
  • RA, CA and repository

Now that we know what an “ID” is we can quickly understand the big picture with X509v3 certificates.

A X509v3 certificate must contain:

  • Serial Number: unique for each issuer
  • Subject Distinguished Name: subject’s Name (X500)
  • Issuer Distinguished Name: issuer’s name (X500)
  • Not Before: the earliest date/time the certificate may be used
  • Not After: the last date/time the certificate may be used
  • Public Key: how the certificate is bound to the subject
  • Signature Algorithm: how the issuer’s signature is made
  • Signature: how the certificate is bound to the issuer

As you can see the certificate contains the core characteristics of an ID – it identifies the subject, issuer, a way to identify the subject (the key), a way to prove the issuer produced the certificate (the signature), and immutability (again, the signature).

The serial number has an arbitrary length. Many CAs use a UUID so you must be prepared to handle at least that many digits.

The subject and issuer are identified by X500 names. This is the same format used by LDAP directories and in fact they’re part of the same set of standards. You should try to adhere to conventions even if you will only use your certificates internally – it gives you the best shot at reusing existing software libraries and applications.

The most important X500 name attribute for servers is the “Common Name” (CN) – many applications require it to match the server’s hostname or DNS name.

A “self-signed” certificate uses the same value for subject and issuer.

The “not before date” and “not after date” are self-explanatory. The date range of a certificate should not exceed the date range of the signing certificate.

The “signature” is a cryptographic signature of the contents of the certificate. It is made with the issuer’s private key and can be verified with the issuer’s public key. The issuer’s public key may be known to the client through other trusted means or via PKIX (public certificate authorities). The signature should not be blindly trusted.

Digital certificates are encoded in a well-known predecessor to XML: ASN.1 (Abstract Syntax Notation One). Each field is tagged with a tree of numbers, e.g., “1.2.840.113549.1.1.11”, to identify its contents. These numbers are registered at a central authority so they’re always unique – you don’t have to worry about two companies using the same tag for different purposes.

You should always use a library to read and write ASN.1 documents. The format is difficult to work with and there’s no benefit in rolling your own.

Extensions

X509v3 certificates offer several standard extensions and an issuer can always add its own extensions as well – just remember to go through the formal process to get unique ASN.1 tags.

Extensions can be marked ‘critical’ or ‘noncritical’. The user of a certificate is expected to gracefully handle noncritical extensions but must understand and handle any critical extensions. If a critical extension is not understood the certificate should be refused.

Basic Constraint

This critical extension indicates whether a certificate can be used to sign other certificates. There is no technical reason why you can’t use any certificate to sign another certificate but PKIX policy (discussed later) requires this.

The basic constraint has an optional “certificate path length” that indicates how deep the certificate chain can be below this point. It can be used to delegate authority by creating certificates that can be used to sign normal “leaf” certificates but not additional “signing” certificates.

Subject Alternate Names

This noncritical extension contains one or more alternate name for the subject. The most common uses are email address or IP Address (for servers).

N.B., there is a well-known hack that can embed an email address in an X500 name but this technique is more correct. In practice many clients ignore this extension so you should use both approaches.

Issuer Alternate Names

Same thing, but for issuers instead of subjects.

Key Usage

This critical extension indicates the acceptable usages for this certificate. There are a number of flags but the overall gist is that you can use these flags to indicate whether a certificate should be used to sign other certificates, for servers, or for individuals. You usually want separate certificates for each purpose.

Flags:

  • Digital Signature
  • Nonrepudiation
  • Key Encipherment
  • Data Encipherment
  • Key Agreement
  • Key Certificate Signing
  • CRL Signing
  • Encipher Only
  • Decipher Only

Extended Key Usage

This noncritical extension elaborates on acceptable usages.

Subject Key Identifier

This noncritical extension offers a standard shorthand reference for the certificate’s public key. It is a good searchable index since the public key itself can have arbitrary length.

Authority Key Identifier

This noncritical extension offers a standard shorthand reference for the certificate’s issuer’s public key. This can be used to quickly establish certificate chains.

Search Criteria

There are several search criteria identified by RFC4387. They can give you an idea about what creates a good search key. (Note: a truncated search key is fine for your own use – you only need the full search key if you have a public certificate repository.)

Certificate Hash / Fingerprint

This is the SHA-1 hash of the entire certificate (in DER format). You can easily get this using OpenSSL tools.

Name

The subject’s Common Name.

sHash

The Base64-encoded SHA-1 hash of the subject’s DN, in DER format. OpenSSL provides a truncated form of this in hex.

iHash

The same thing but for the issuer.

iAndSHash

The Base64-encoded SHA-1 hash of the certificate’s issuer and serial number. The last values should be unique.

sKIDHash

The base64-encoded SHA-1 hash of the certificate’s subject key identifier. This hash is on the key identifier itself, not the entire SKID extension.

In the real world…

In the real world clients often do not check or honor the extensions. Certificate authorities may use expired certificates or certificates lacking the basic constraint.

The bottom line is that you have to have very low standards if you accept public certificates. In contrast certificates intended for internal use can and should be carefully checked.

Vulnerabilities and Attacks

The serial number, X500 names, and public key have essentially unlimited length. This must be kept in mind if you accept certificates from the public – malicious certificates have been seen that attempt to trigger buffer overruns in order to execute arbitrary code.

For More Information

RFC2459: Internet X.509 Public Key Infrastructure | Certificate and CRL Profile

RFC4387: Internet X.509 Public Key Infrastructure | Operational Protocols: Certificate Store Access via HTTP

The Legion of the Bouncy Castle

X.509 Public Key Certificate and Certification Request Generation

Danger, Danger, Will Robinson!

If you read nothing else in this series, read this!

Top 10 PKI Risks

Everything you Never Wanted to Know about PKI but were Forced to Find Out (Peter Gutmann)

Categories
java, security
Comments rss
Comments rss
Trackback
Trackback

« Introduction to Digital Certificates, Part 2: IDs Introduction to Digital Certificates, Part 4: Creating Certs with Bouncy Castle »

Leave a Reply

Click here to cancel reply.

You must be logged in to post a comment.

Archives

  • May 2020 (1)
  • March 2019 (1)
  • August 2018 (1)
  • May 2018 (1)
  • February 2018 (1)
  • November 2017 (4)
  • January 2017 (3)
  • June 2016 (1)
  • May 2016 (1)
  • April 2016 (2)
  • March 2016 (1)
  • February 2016 (3)
  • January 2016 (6)
  • December 2015 (2)
  • November 2015 (3)
  • October 2015 (2)
  • August 2015 (4)
  • July 2015 (2)
  • June 2015 (2)
  • January 2015 (1)
  • December 2014 (6)
  • October 2014 (1)
  • September 2014 (2)
  • August 2014 (1)
  • July 2014 (1)
  • June 2014 (2)
  • May 2014 (2)
  • April 2014 (1)
  • March 2014 (1)
  • February 2014 (3)
  • January 2014 (6)
  • December 2013 (13)
  • November 2013 (6)
  • October 2013 (3)
  • September 2013 (2)
  • August 2013 (5)
  • June 2013 (1)
  • May 2013 (2)
  • March 2013 (1)
  • November 2012 (1)
  • October 2012 (3)
  • September 2012 (2)
  • May 2012 (6)
  • January 2012 (2)
  • December 2011 (12)
  • July 2011 (1)
  • June 2011 (2)
  • May 2011 (5)
  • April 2011 (6)
  • March 2011 (4)
  • February 2011 (3)
  • October 2010 (6)
  • September 2010 (8)

Recent Posts

  • 8-bit Breadboard Computer: Good Encapsulation!
  • Where are all the posts?
  • Better Ad Blocking Through Pi-Hole and Local Caching
  • The difference between APIs and SPIs
  • Hadoop: User Impersonation with Kerberos Authentication

Meta

  • Log in
  • Entries RSS
  • Comments RSS
  • WordPress.org

Pages

  • About Me
  • Notebook: Common XML Tasks
  • Notebook: Database/Webapp Security
  • Notebook: Development Tips

Syndication

Java Code Geeks

Know Your Rights

Support Bloggers' Rights
Demand Your dotRIGHTS

Security

  • Dark Reading
  • Krebs On Security Krebs On Security
  • Naked Security Naked Security
  • Schneier on Security Schneier on Security
  • TaoSecurity TaoSecurity

Politics

  • ACLU ACLU
  • EFF EFF

News

  • Ars technica Ars technica
  • Kevin Drum at Mother Jones Kevin Drum at Mother Jones
  • Raw Story Raw Story
  • Tech Dirt Tech Dirt
  • Vice Vice

Spam Blocked

53,793 spam blocked by Akismet
rss Comments rss valid xhtml 1.1 design by jide powered by Wordpress get firefox