As I recall the CER extension stands for "Canonical Encoding Rules" and not "certificate" as I first thought and is somehow related to DER "Distinguished Encoding Rules" or BER "Basic Encoding Rules". I'm not sure how they all relate but I think a digital certificate is binary unless it's Base64 encoded (PEM) as you say.
Thanks ________________________________________ From: owner-openssl-us...@openssl.org [owner-openssl-us...@openssl.org] on behalf of sandeep kiran p [sandeepkir...@gmail.com] Sent: Saturday, October 01, 2011 10:19 AM To: openssl-users@openssl.org Subject: Re: Is certificate a CA or Client Certificate Are you sure there is an ExtendedKeyUsage indicating a "Certificate Sign" OID? Cert Sign AFAIK is only indicated in KeyUsage extension. -Sandeep On Sat, Oct 1, 2011 at 9:24 AM, <jb-open...@wisemo.com<mailto:jb-open...@wisemo.com>> wrote: On 01-10-2011 01:09, Dave Thompson wrote: From: owner-openssl-us...@openssl.org<mailto:owner-openssl-us...@openssl.org> On Behalf Of jb-open...@wisemo.com<mailto:jb-open...@wisemo.com> Sent: Thursday, 29 September, 2011 18:46 Because the attributes mentioned are only meaningful if covered by the digital signature on the certificate, it cannot change in any format conversion that keeps the certificate valid. The true format of certificates is binary BER encoded X.509. A .cer file is simply that structure directly. Yes, or sometimes converted to PEM format. PEM is the binary represented in base64 plus dashes-BEGIN-x and dashes-END-x lines. It looks different in e.g. notepad but is fundamentally the same. I was trying to keep it simple for the OP. In fact both .cer and .p7b files can be Base64 encoded PEM style. PEM encoding a .p12/.pfx file is less useful and might not even be allowed. A P7b/PKCS#7 file is really a digitally signed message with zero or more attached signatures to help the recipient to check the signature, each OYM attached *certificates* to help check the signature(s) Sorry, typo, I was in a hurry when I wrote the message. certificate is the same X.509 BER structure, just placed inside a list (SEQUENCE) inside a PKCS#7 structure (which is also BER encoded just like the certificate). When using a P7b file to transport certificates, the message and signature fields are just left blank. A P12/PFX/PKCS#12 file is an encrypted file which stores various certificates (the same X.509 BER structure as before), various private keys and hints on where these items should be imported into CryptoAPI and/or the old Netscape browser. Yes. So whatever the format, after loading and unpacking, you are left with an X.509 structure which contains a few mandatory fields (such as Subject, Issuer, Public Key, Private Key, Serial Number), NOT PrivateKey! Also validityPeriod (start-time and end-time). BTW originally serialNumber often was truly serial (1, 2, 3, etc.) but for some time now it has been more common to make it a large unique (random or obscured) number. Oops! big typo, of cause not the private key. "Such as" means there are other fields not mentioned. and a lot of optional fields. One of those optional fields is a list of "authenticated attributes". Each entry in that list has Although included in the signed part, it is just called 'extensions'. 'authenticatedAttributes' and separate 'unauthenticatedAttributes' are fields in PKCS#7/CMS SignedData. Sorry about that, Its hard to keep track of these subtle variations without looking them up. a "type OID", a "critical" flag and some data. The entries may be found in any order, your code needs to work whatever field entry comes first, needs to ignore any entry whose "type OID" you don't understand. You can ignore an extension you don't understand if it is non-critical; you should give an error if it is critical and you are actually relying on the cert for something. If just looking at a specific extension, as here, you don't need to even see other/unknown extensions. I would have mentioned it, but for the OPs problem (deciding the certificate category), ignoring critical extensions is fine, so I removed that part from my post before hitting send. The optional "CA" occurs in this list as an entry with the "CA" OID and a TRUE/FALSE value. So CA may be "not there", TRUE or FALSE. Actually the extension is BasicConstraints; it contains CA: boolean and pathLen: OPTIONAL INTEGER. You can have: - omitted - CA=false - CA=true pathlen=unspecified - CA=true pathlen=somenumber For deciding 'CA or not' pathlen doesn't matter. Oh, I forgot it was in the same Ext, this may affect any manual parsing the OP might write. The optional "Key Usage" also occurs in this list as an entry with the "Key Usage" OID and a value which is a list of OIDs (one for each usage). So Key Usage mat be "not there", "there" with the "certificate sign" OID listed in its value, or "there" without the "certificate sign" OID in its value. You have two things conflated here. KeyUsage value is 9 predefined bits, including certSign. *Extended*KeyUsage value is a list of extensible OIDs. A cert can have either or both or neither. If you have both and they conflict, reliers should reject. Oops, I really was a bit fast yesterday, so there are really 3 exts to check for "can act as a CA at all": - BasicConstraints (look for CA:TRUE bit) - KeyUsage (look for "certificate sign" bit being set) - ExtendedKeyUsage (look for "certificate sign" OID in list) If any of these 3 are present, it is a CA (root or intermediate) If none of these 3 are present, it is an end entity cert (CA issued or toy). I don't remember the function names to look at the "authenticated attribute" list in OpenSSL and/or CryptoAPI, but there should be functions that will let you check if the list is there at all, and if so loop over all the entries, looking at each to see if it is one you care about today. OpenSSL: AFAICS the functions never distinguish between extensions omitted entirely or present but empty (zero-length sequence), which should make no semantic difference to anyone ever. But unlike some other OpenSSL data structures these aren't hidden, so you can just look if you really care. Or you can just ask for a particular extension by OID or NID (which is OpenSSL's internal equivalent). And for this particular decision you can just call X509_check_ca which isn't in the manpage but is public in x509v3.h and appears to have been stable for years. It checks KU and BC.CA<http://BC.CA> if present, or otherwise does some guessing that looks reasonable to me and even if you disagree you might use it as a starting point. On 29-09-2011 17:33, Harshvir Sidhu wrote: <snip> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org<mailto:openssl-users@openssl.org> Automated List Manager majord...@openssl.org<mailto:majord...@openssl.org> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
