Re: Distinguishing a CA certificate from an end entity certificate Reg.
On 2012-02-24 00:58 +0530 (Fri), Ashok C wrote: > We too have the use cases of those four certificates. Now what would be the > best programmatic way to find out for sure if a given certificate is a CA > certificate or not, be it a v3 or a v1. Well, in the end, given your conditions, you can't be absolutely sure. For v1 certificates, it's not the certificate itself but how it's used that determines of it's a "CA certificate" or not. This actually common to a lot of things in the X.509 world: the syntax is well defined, but the semantics are not. So when it comes to precise semantics, you use what others are using in their particular corner of the PKI world, or define them yourself if you're in your own corner. This is why we have not only the X.509 standards, but profiles of them such as RFC 5280 (Internet X.509 Public Key Infrastructure, or PKIX) and RFC 2818 (HTTP Over TLS). (Anybody, please feel free to correct me if I'm wrong, but this is basically what I've gotten from many hours of study on this over the last few months in preparation for setting up my own PKI.) cjs -- Curt Sampson +81 90 7737 2974 http://www.starling-software.com/ I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. --Bjarne Stroustrup __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Distinguishing a CA certificate from an end entity certificate Reg.
Thanks Jakob, We too have the use cases of those four certificates. Now what would be the best programmatic way to find out for sure if a given certificate is a CA certificate or not, be it a v3 or a v1. Regds, Ashok On Feb 24, 2012 12:51 AM, "Jakob Bohm" wrote: > On 2/23/2012 10:49 AM, Ashok C wrote: > >> Hi, >> >> What would be the most efficient and easiest way to distinguish a CA >> certificate from an actual server/client(end entity) certificate? >> We were thinking of identifying the CA with the "CA:TRUE" constraint from >> the text display, but again this check does not cover x509 v1 certificates >> where this extension is not present. >> Is there any command/openSSL API available which would serve this purpose? >> >> > Ah, a classic FAQ. I think I answered a very similar question > last year, but here we go again. > > In practice you need to distinguish 4 kinds of certificate: > > 1. CA Root. Recognized by being signed by itself (Subject > Distinguished Name exactly same as Issuer Distinguished Name), > by having the CA property not set to FALSE (in other words, it > is TRUE or absent), by having the similar flags and bits in > the other usage properties also allowing use as a CA and by > usually having one of the words "ROOT" or "CA" as a word > substring of its common name (CN in the Subject). (A word > substring is a substring bordered on both sides by end/start > of string or by a non-letter). > > 2. Intermediary CA. Recognized by NOT being signed by itself, > but still having the various usage properties allowing or not > preventing use as a CA. > > 3. Self-Signed End Entity. Recognized by being signed by > itself, but failing one or more of the other checks for being > a CA root, and/or by having a subject name which is directly > usable for an end entity (e.g. a domain name or e-mail > address). These tend to be created quite sloppily, so the > only sure test is if someone uses it as an end entity > certificate. The next best test is that anything not on > YOUR list of trusted CA roots is not a CA root until overridden > by human intervention based on hard offline evidence. > > 4. Regular End Entity. Recognized by NOT being signed by > itself AND being explicitly marked with one or more attributes > preventing use as a CA (most professional CA's don't allow end > entity certificates to act as intermediary CAs, as it would > completely nullify their identity checking efforts and thus > the trustworthiness of their root CA cert). > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com > Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > __**__**__ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Re: Distinguishing a CA certificate from an end entity certificate Reg.
On 2/23/2012 10:49 AM, Ashok C wrote: Hi, What would be the most efficient and easiest way to distinguish a CA certificate from an actual server/client(end entity) certificate? We were thinking of identifying the CA with the "CA:TRUE" constraint from the text display, but again this check does not cover x509 v1 certificates where this extension is not present. Is there any command/openSSL API available which would serve this purpose? Ah, a classic FAQ. I think I answered a very similar question last year, but here we go again. In practice you need to distinguish 4 kinds of certificate: 1. CA Root. Recognized by being signed by itself (Subject Distinguished Name exactly same as Issuer Distinguished Name), by having the CA property not set to FALSE (in other words, it is TRUE or absent), by having the similar flags and bits in the other usage properties also allowing use as a CA and by usually having one of the words "ROOT" or "CA" as a word substring of its common name (CN in the Subject). (A word substring is a substring bordered on both sides by end/start of string or by a non-letter). 2. Intermediary CA. Recognized by NOT being signed by itself, but still having the various usage properties allowing or not preventing use as a CA. 3. Self-Signed End Entity. Recognized by being signed by itself, but failing one or more of the other checks for being a CA root, and/or by having a subject name which is directly usable for an end entity (e.g. a domain name or e-mail address). These tend to be created quite sloppily, so the only sure test is if someone uses it as an end entity certificate. The next best test is that anything not on YOUR list of trusted CA roots is not a CA root until overridden by human intervention based on hard offline evidence. 4. Regular End Entity. Recognized by NOT being signed by itself AND being explicitly marked with one or more attributes preventing use as a CA (most professional CA's don't allow end entity certificates to act as intermediary CAs, as it would completely nullify their identity checking efforts and thus the trustworthiness of their root CA cert). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Distinguishing a CA certificate from an end entity certificate Reg.
On 02/23/2012 10:49 AM, Ashok C wrote: Hi, What would be the most efficient and easiest way to distinguish a CA certificate from an actual server/client(end entity) certificate? We were thinking of identifying the CA with the "CA:TRUE" constraint from the text display, but again this check does not cover x509 v1 certificates where this extension is not present. Is there any command/openSSL API available which would serve this purpose? a v1 certificate (if you want) or v3 cert with both CA:true*and keyusage has certsign bit. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Distinguishing a CA certificate from an end entity certificate Reg.
Hi, What would be the most efficient and easiest way to distinguish a CA certificate from an actual server/client(end entity) certificate? We were thinking of identifying the CA with the "CA:TRUE" constraint from the text display, but again this check does not cover x509 v1 certificates where this extension is not present. Is there any command/openSSL API available which would serve this purpose? Regds, Ashok
