My root certificates are stored as several files in ASN.1 format.
Assume I have a chained end entity certificate in the same format. How do I efficiently determine the root certificate of this certificate?
Currently I have to take a brute force approach which extracts the public key of the end entity certificate and validates that against all root certificates and the first match is considered the root certificate. Is this the right approach??
To find the issuer of a certificate, you should use the "Issuer DN" and match it with the "Subject DN" of the certificates in your CA store. This should reduce significantly the number of signature verification.
It is possible to have different CA certificates with the same "Subject DN" (with different public keys, validity dates, etc.), so your algorithm should be prepared to handle that. The "Subject Key Identifier" and "Authority Key Identifier" can also help to reduce the number of candidates.
Finding the issuing authority is only a small part of the "right approach" to validating certificates. I would advise you to look at part 6 of http://www.ietf.org/rfc/rfc5280.txt "Certification Path Validation". Some parts are most probably overkill (i.e. most things having to do with policies).
Related
How would a certificate authority create and maintain a certificate revocation list? When I browse through some CRLs I notice the number of certificates are huge (Eg - http://crl3.digicert.com/ssca-sha2-g6.crl)
Is the CRL maintained/stored as a List<thumbprint, revocationDate> ?
What does a revocation check look like? Is it internally maintained as a HashMap for quicker lookup, but does that scale if the list goes too big?
Here is the specification: https://www.rfc-editor.org/rfc/rfc5280
Depending on the implementation often databases are used internally as source to produce the CRLs.
I've generated a key-pair using keytool -genkeypair command. I presume this create a pair of private key and public key.
I've also generated a CSR out of this key-pair using the keytool -certreg command. I got it signed by our CA (or whatever they call it) and I got another certificate in return along with it is its thumbprint.
My question is, what am I going to use that certificate for or what is its purpose? I'm still able to generate a JWT just using the private key.
A key is a set of mathematical parameters describing how to initialize certain algorithms for cryptographic operations, e.g. for signing/verification or for encryption/decryption.
A key pair merely is a pair of such keys where each key can verify what the other one has signed or where each key can decrypt what the other one has encrypted.
One key in such a pair is declared the public key and the other one the private key. (This choice is not completely arbitrary, there can be different extra requirements to a private key than to a public one.)
There is nothing in these keys declaring that they are bound to a specific person, to a specific issuer, to a specific purpose, to a specific accountability, etc.
This is where X.509 certificates come into the picture: A X.509 certificate is a structure that bundles the public key of a key pair with extra information like the name of the holder of the key pair, the name of an issuer of the certificate, validity time spans, and much more.
This structure furthermore contains a signature of all those other data in the structure. This signature is generated using the private key of the issuer of the certificate.
The information in the certificate in particular allows you to determine the issuer of it. If you trust organization of the issuer to only issue certificates to persons whose identity they checked, and if you successfully validated that the certificate signature is valid and created by the issuer, you can trust the identity of the holder of the key pair of a given certificate.
Thus,
My question is, what am I going to use that certificate for or what is its purpose? I'm still able to generate a JWT just using the private key.
you provide your certificate publicly to allow people to be sure of your identity when they use the contained public key to validate your signatures or encrypt information they send to you. Without a mechanism like the certificates you'd have to give people your public key in person for them to be sure of that.
Provided I have a valid CA issued .cert file. Technically, how many keys a single .cert file can have? more than one public key? or only one public key
As said in comments, an X.509 certificate (RFC5280) contains exactly one public key. No more, no less.
For same subject, will CA issue more than one certificates?
CA may issue as many certificates to same entity as necessary. There are no limitations on the amount of issued certificates per subject.
I assume that this is possible based on the fact that both utilize RSA for encryption. I should be able to read X.509 and store it as a new OpenPGP key.
The collaborator of my software needs OpenPGP.
Another collaborator provides X.509.
I am looking for a way to convert the keys.
Is that possible, how would one do that?
The short version: you can somewhat, but there is rarely good use in doing so.
You can extract the numbers forming the key and theoretically put together a new X.509 and/or OpenPGP key from them, but those would still remain incompatible, different keys in the respective system. Actually, the monkeysphere project brings tools for both directions (openpgp2pem and pem2openpgp, but make sure to read the rest of the post before heading out and converting keys).
Both X.509 and OpenPGP are more than a file format for keys: they add (incompatible) options for key management and certification, metadata, identifiers, ... Also, both systems use slightly different cryptographic modes of operation, and have very different (and thus incompatible) formats for encrypted and signed messages. They even have enormous differences in how certifications are handled (hierarchical structure in case of X.509 vs. an arbitrary graph in case of OpenPGP).
With other words: anything you do with the X.509 "representation" of an OpenPGP key sharing the same RSA primes cannot be used with the OpenPGP variant, and the other way round. Certificates issued in one system don't work in the other (and cannot be converted!).
As both keys "representations" are incompatible anyway and have to be managed separately, I would strongly recommend to create different sets of keys from beginning. After all, this adds another layer of security in case one of the keys is breached, as the other key stayed undamaged. Apart from performing unusual operations is always error-prone and suspicious to follow-up issues.
There might be good use cases, for example the monkeysphere project requires those conversions for authenticating SSH connection through OpenPGP keys. But I would not consider general usage for signing and encrypting messages and files a good use case for the reasons given above.
Is there a particular order in which the subject attributes - C, ST, L, O, OU, CN have to specified. openssl does not seem to enforce an order.
And while generating the Distinguished Name do we pick up all the subject attributes configured in the certificate? Does the ordering of the attributes matter ?
In theory, it doesn't matter but in practice, some crypto libraries are not able to build a chain if the order of tokens in the subject of parent certificate is different than the order of tokens in issuer field in child certificate. They should be exactly the same if you don't want to have any strange issues.
For example, even the windows 10 tool (mmc) doesn't display correctly the chain if the order of tokens in the subject/issuer field is different.
Is there a particular order in which the subject attributes - C, ST, L, O, OU, CN have to specified.
There is no order specified as far as I know. Order that you specify will be used and in this order will DN be generated in i.e. PKCS#10 request.
And while generating the Distinguished Name do we pick up all the subject attributes configured in the certificate?
CA may (and most probably will) use DN from your PKCS#10 request when issuing certificate but it can decide on a different order. Some RDNs (Relative Distinguished Names) can be moved to extensions, i.e. emailAddress or copied to extensions like CN to SubjectAlternativeName when issuing SSL server certificate.
Does the ordering of the attributes matter ?
Ordering does not IMHO matter. It might matter to some application that is consuming the certificate but in general ordering does not matter.