How to handle OpenSSL and not get hurt background information
Back to top How to handle OpenSSL and not get hurt
OpenSSL oneline format
OpenSSL uses a more readable format then RFC2253 (aka X500Name). The format is a defacto for wide variety of tools, services and infrastructures. To the best of my knowledge it was Globus which adopted the format for the grid-mapfile. This file authorizes users based on their certificate's subject DN and specifies a one-to-one mapping between a subject DN and a local Unix system account. In the time IBM has adopted it for their Grid middleware as many others have followed in the footsteps of Globus.
To see the OpenSSL oneline format at work, you'll have to dive into the command line and try it to see both the Subject DN and the Issuer DN:
Vision:~ okoeroo$ openssl x509 -noout -in usercert.pem -subject subject= /O=dutchgrid/O=users/O=nikhef/CN=Oscar Koeroo issuer= /C=NL/O=NIKHEF/CN=NIKHEF medium-security certification auth
The output shows DN for both the issuer and the subject. In the oneline format the Relative Distinguished Name (RDN). RDNs are separated by slash-signs. Although a DN MUST be read as is, in the oneline-format the left-most RDN is the most significant RDN when taking the build-up of its sub-components into account. This differs per printable string format.
Each RDN is a attribute and multi-valued pair. The attribute name is a registered OID. Usually only one value is associated to each attribute. The value is a UTF8String in the ASN.1 sequence, though commonly only ASCII characters are used because a lot of middleware is unable to handle UTF8 characters. The oneline notation describes the binding between an OID and a value with a equal-sign. The separator between multiple values is the plus-sign.
Less information can be found here: http://www.openssl.org/docs/apps/x509.html#item_oneline
The Distinguished Name in detail
The DN is a sequence of Relative Distinguished Names (RDNs), described in RFC2253 (though superseeded by another one that I need to lookup). The International Grid Trust Federation (IGTF), its PMAs (European Policy Management Authority (EUGridPMA), Asia Pacific Grid Policy Management Authority (APGridPMA) and The Americas Grid Policy Management Authority (TAGPMA)) and TERENA Academic CA Repository (TACAR) have scoped the usage of the available RDNs in CA due to the fact that different printable string representations of the same RDN Object Identifiers (OID) have been used or that the same printable string has been associated to different registered OIDs. Which makes the practical usage between inter-operating middleware which can be based in Java, C, Python, Perl, OpenSSL, Bouncycastle, GnuTLS and homebrew solutions impossible.
The DN is build up based upon the openssl.cnf file used by the CA during the signing process. Each CA SHOULD use a private namespace and declare the namespace publicly. CAs, like those in the International Grid Trust Federation (IGTF), will not overlap in their namespaces. Commercial CAs tend to have a declared name space of .*, hence they do not limit their signing namespace by any shape or form. This makes certificates from commercial CAs inherently non-unique and therefore not very usable in a global Grid environment without additional policies in place.
The general 'how do (proxy) certificates work' and 'what is a proxy certificate'
When (identity) delegation are used in a world full of X.509 certificates it means that you are using proxy certificates. Proxy certificates come in various shapes, forms and types. Some of the basics properties are consistent:
- It's an X.509 certificate
- Has a public and private key pair.
- The first delegated proxy certificate is signed by an End-Entity Certificate (EEC). An EEC means your personal certificate.
- Proxy certificates can signed and follow other proxy certificates
A certificate chain with one delegation, will be constructed like this:
- CA certificate
- EEC (personal, server or service certificate)
- proxy certificate
In short, the construction steps (certificate "Genesis") to a proxy certificate:
- The CA operator creates a key pair and a signing request for the root CA certificate
- The CA operator (self-)signs its own request with its own private key
- A user creates a key pair, a signing request and send that off to a CA operator
- The CA operator performs identity vetting on the user and its signing request
- The CA operator creates the certificate from the signing request, signs it with the CA's private key and returns a brand new certificate to the user
- The user can use {grid,voms}-proxy-init to generate a new keypair, signing request for the proxy certificate and sign the proxy certificate with his/her private key.
Adding another proxy certificate layer is a repeat of the final step, but instead of using the user's certificate and private key, the certificate and private key of the latest created proxy certificate are used to create the next delegation and sign that proxy certificate.
A more complex certificate chain:
- CA certificate
- intermediate or sub-CA certificate
- yet another intermediate or sub-CA certificate
- EEC (personal, server or service certificate)
- proxy certificate
- another proxy certificate
Proxy Certificate and CA Certificate Path Length Constraint - RFC Text vs. What to implement
The RFC 5280 and RFC 3820 mention how (Proxy) Path Length Constraints are formalized, but the edge cases are not specified. For example if a CA certificate indicates a pathLenConstraint of 2, could the first next CA stricten the policy by setting a PathLenConstraint of 0? The same holds (more likely) true for proxy certificates.
My interpretation of the standard is:
Yes, you can make it more strict. A proxy or CA certificate could set a pathLenConstraint value of 10, and scope it in one of its delegation branches to 0. This makes the most sense.
But now, the other way around. Could a CA or Proxy certificate indicate a pathLenConstraint of 2, while its first next Proxy or CA certificate sets a pathLenConstraint of 10 to override the first set pathLenConstraint?
My interpretation of the standard is:
No, you can never extend a lower value for the pathLenConstraint by a higher number.
SHA-2 support in software
Here is a quite complete compatibility list with respect to SHA-2 offered at Logius, the entity behind the Dutch PKI Overheid:
The SSL* object/struct and a complete certificate chain
The SSL* object will hold the certificate chain and an individual certificate based by a client (when the client is offering a client-side certificate) and vice-versa on the client side the SSL* object will contain the certificate chain and the individual certificate of the service the client connected to. Take note that the End-Entity Certificate or the final delegation (read: proxy certificate, regardless of RFC3820 comliance) is handled differently from the entire certificate chain. (Note to self, I need to read RFC to see if this is an RFC related choice or OpenSSL specific).
The certificate chain you'll get exists only of all the certificates except the last one. Normally these are all the CAs. In case of the use of (RFC3820 compliant) proxy certificates this could also include the EEC and even all the intermediate proxy certificates, upto and not including the final delegation.To get the final delegation, or in normal use case the EEC, you'll need to specifically get that from the SSL* object.
See SSL_get_peer_certificate() and SSL_get_peer_cert_chain(). And how sk_X509_insert() could become useful.
SSL structures and their interrelationship
Quoting "openssl-1.0.1c/include/openssl/x509_vfy.h":
SSL_CTX -> X509_STORE
-> X509_LOOKUP
->X509_LOOKUP_METHOD
-> X509_LOOKUP
->X509_LOOKUP_METHOD
SSL -> X509_STORE_CTX
->X509_STORE
The X509_STORE holds the tables etc for verification stuff. A X509_STORE_CTX is used while validating a single certificate. The X509_STORE has X509_LOOKUPs for looking up certs. The X509_STORE then calls a function to actually verify the certificate chain.
