Intermediate signing certs
Hello, If you have a signing hierarchy of A signs B, B signs C, and C signs D, so that A is your root CA and D is the end user certificate. If I want to check that D is signed by A, does that mean that intermediate signers B and C also have to be present in the certificate stack, or what openssl refer to as the cert chain? Would this be a hassle if you have a root CA with a lot of intermediate signers? That means that you have to store/locate all possible intermediate signers to evaluate a couple of end user certificates. Tat. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Intermediate signing certs
A, B and C need to be available to the certificate verification process if you wish to check that D was signed by C, which was signed by B, which was signed by A. > -Original Message- > From: Tat Sing Kong [mailto:[EMAIL PROTECTED]] > Sent: 10 December 2001 17:01 > To: Openssl-Users@Openssl. Org > Subject: Intermediate signing certs > > > > Hello, > > If you have a signing hierarchy of A signs B, B signs C, and > C signs D, so > that A is your root CA and D is the end user certificate. If > I want to > check that D is signed by A, does that mean that intermediate > signers B and > C also have to be present in the certificate stack, or what > openssl refer to > as the cert chain? > > Would this be a hassle if you have a root CA with a lot of > intermediate > signers? That means that you have to store/locate all > possible intermediate > signers to evaluate a couple of end user certificates. > > Tat. > > > > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Intermediate signing certs
It's not REQUIRED that all certs in the chain be there, but it will probably be useful -- at least the first time. :) > Would this be a hassle if you have a root CA with a lot of intermediate > signers? That means that you have to store/locate all possible intermediate > signers to evaluate a couple of end user certificates. Yes. Welcome to the "fun" of path validation. /r$ -- Zolera Systems, Your Key to Online Integrity Securing Web services: XML, SOAP, Dig-sig, Encryption http://www.zolera.com __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Intermediate signing certs
> Would this be a hassle if you have a root CA with a lot of intermediate > signers? That means that you have to store/locate all possible intermediate > signers to evaluate a couple of end user certificates. This is why PKCS12 (iirc) provides a mechanism to provide intermediate certs with the final cert. The CA should have a suitable chain for its own certs, and it can return the extra certs with everything that it signs. This doesn't help you when presented a naked cert by a stranger - you still have to locate those intermediate certs - but at that point you have more problems than just finding the intermediate certs. What does it mean to have a full cert chain if the root is a self-signed cert by "Bob's Bait Shop and Certificate Authority?" You could decide to ignore any cert that's not from a major CA (which would make the stockholders of Verisign very happy), but that misses the point. An individual cert by Verisign really says very little about the person, a cert signed by a small college for its students for internal use may be rock solid. On a related note, is there documentation on how to set up a "well- behaved" certs and PKCS12 bags? I couldn't find anything the last time I checked, but maybe something has come out since then. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Intermediate signing certs
On Mon, 10 Dec 2001, Bear Giles wrote: > > Would this be a hassle if you have a root CA with a lot of intermediate > > signers? That means that you have to store/locate all possible intermediate > > signers to evaluate a couple of end user certificates. > > This is why PKCS12 (iirc) provides a mechanism to provide intermediate > certs with the final cert. The CA should have a suitable chain for its > own certs, and it can return the extra certs with everything that it > signs. This likely applies to PKCS7 Signed structure. > This doesn't help you when presented a naked cert by a stranger - you > still have to locate those intermediate certs - but at that point you > have more problems than just finding the intermediate certs. What does > it mean to have a full cert chain if the root is a self-signed cert by > "Bob's Bait Shop and Certificate Authority?" Any parseable certificate presented by a strager is good enough to use that public key to send email encrypted to *his* private key. At least if there's no chance for man-in-the-middle. Probably you are talking about verification that stranger is authorized by some big guy to pay..it's completely different issue. Yes, one need (root) certificate of that big guy and intermed certs to verify the chain. > You could decide to ignore any cert that's not from a major CA (which > would make the stockholders of Verisign very happy), but that misses > the point. An individual cert by Verisign really says very little about > the person, a cert signed by a small college for its students for > internal use may be rock solid. One could care about CA certificates related to his business, either well-known or private ones used to verify access to local resources. > On a related note, is there documentation on how to set up a "well- > behaved" certs and PKCS12 bags? I couldn't find anything the last > time I checked, but maybe something has come out since then. Any problem with PKCS12 specifications published by RSA Labs? What is "well-behaved" ? -vf __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Intermediate signing certs
That's me told then, so to authenticate a certificate you need the whole "chain" of certs going from the cert to authenticate all the way to a trusted CA. The application I am writing is presented with certs to authenicate from an external source, and the configuration has to hold a "pool" of trusted certs so you can check the certificates presented. It appears that this "pool" has to basically have every possible signer in it. I was kind of hoping that I could get away with only a couple of trusted CA's; and traverse the certificate hierarchy to these roots. Hold on, I can't do that because without the intermediate signer certs how can I figure out who signed them? Got it now. Tat. > > > Would this be a hassle if you have a root CA with a lot of > intermediate > > > signers? That means that you have to store/locate all > possible intermediate > > > signers to evaluate a couple of end user certificates. > > > > This is why PKCS12 (iirc) provides a mechanism to provide intermediate > > certs with the final cert. The CA should have a suitable chain for its > > own certs, and it can return the extra certs with everything that it > > signs. > > This likely applies to PKCS7 Signed structure. > > > This doesn't help you when presented a naked cert by a stranger - you > > still have to locate those intermediate certs - but at that point you > > have more problems than just finding the intermediate certs. What does > > it mean to have a full cert chain if the root is a self-signed cert by > > "Bob's Bait Shop and Certificate Authority?" > > Any parseable certificate presented by a strager is good enough to > use that public key to send email encrypted to *his* private key. > At least if there's no chance for man-in-the-middle. > > Probably you are talking about verification that stranger is authorized > by some big guy to pay..it's completely different issue. Yes, one need > (root) certificate of that big guy and intermed certs to verify the chain. > > > You could decide to ignore any cert that's not from a major CA (which > > would make the stockholders of Verisign very happy), but that misses > > the point. An individual cert by Verisign really says very little about > > the person, a cert signed by a small college for its students for > > internal use may be rock solid. > > One could care about CA certificates related to his business, either > well-known or private ones used to verify access to local resources. > > > On a related note, is there documentation on how to set up a "well- > > behaved" certs and PKCS12 bags? I couldn't find anything the last > > time I checked, but maybe something has come out since then. > > Any problem with PKCS12 specifications published by RSA Labs? > What is "well-behaved" ? > > -vf __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Intermediate signing certs
On Tue, 11 Dec 2001, Tat Sing Kong wrote: > > That's me told then, so to authenticate a certificate you need the whole > "chain" of certs going from the cert to authenticate all the way to a > trusted CA. It's unlikely just authentication is of any practical use; authorization is and risk of failure to consider. In case of sending encrypted mail to a stranger: would one care authentication at all? One could just use public key from certificate presented and the message could be just lost in case of bad key. Yes, one should exclude main-in-the-middle and create message content to be useful by a stranger. One could also care whether exactly this stranger was here already. It's unlikely any CA could be useful here. > The application I am writing is presented with certs to authenicate from an > external source, and the configuration has to hold a "pool" of trusted certs > so you can check the certificates presented. It appears that this "pool" > has to basically have every possible signer in it. I was kind of hoping > that I could get away with only a couple of trusted CA's; and traverse the > certificate hierarchy to these roots. Hold on, I can't do that because > without the intermediate signer certs how can I figure out who signed them? > > Got it now. > > Tat. > > > > > Would this be a hassle if you have a root CA with a lot of > > intermediate > > > > signers? That means that you have to store/locate all > > possible intermediate > > > > signers to evaluate a couple of end user certificates. > > > > > > This is why PKCS12 (iirc) provides a mechanism to provide intermediate > > > certs with the final cert. The CA should have a suitable chain for its > > > own certs, and it can return the extra certs with everything that it > > > signs. > > > > This likely applies to PKCS7 Signed structure. > > > > > This doesn't help you when presented a naked cert by a stranger - you > > > still have to locate those intermediate certs - but at that point you > > > have more problems than just finding the intermediate certs. What does > > > it mean to have a full cert chain if the root is a self-signed cert by > > > "Bob's Bait Shop and Certificate Authority?" > > > > Any parseable certificate presented by a strager is good enough to > > use that public key to send email encrypted to *his* private key. > > At least if there's no chance for man-in-the-middle. > > > > Probably you are talking about verification that stranger is authorized > > by some big guy to pay..it's completely different issue. Yes, one need > > (root) certificate of that big guy and intermed certs to verify the chain. > > > > > You could decide to ignore any cert that's not from a major CA (which > > > would make the stockholders of Verisign very happy), but that misses > > > the point. An individual cert by Verisign really says very little about > > > the person, a cert signed by a small college for its students for > > > internal use may be rock solid. > > > > One could care about CA certificates related to his business, either > > well-known or private ones used to verify access to local resources. > > > > > On a related note, is there documentation on how to set up a "well- > > > behaved" certs and PKCS12 bags? I couldn't find anything the last > > > time I checked, but maybe something has come out since then. > > > > Any problem with PKCS12 specifications published by RSA Labs? > > What is "well-behaved" ? > > > > -vf > > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List[EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Intermediate signing certs
> > This doesn't help you when presented a naked cert by a stranger[...] > > Any parseable certificate presented by a strager is good enough to > use that public key to send email encrypted to *his* private key. > At least if there's no chance for man-in-the-middle. Not if the cert denies such use... and at most all it gives you is a secure channel back to the person who sent you a possibly fradulent cert. If you aren't willing to blindly trust their cert, why would you blindly trust a cert chain and root cert (or pointer to same) they send? > Probably you are talking about verification that stranger is authorized > by some big guy to pay..it's completely different issue. Or authorized to use resources, access data, etc. At an extreme, it might only be used to log the identity of persons in open discussions. That might sound excessive, but the spammers and slanderers may force some forums to go to this extreme. Anyone who posts as [EMAIL PROTECTED] is exactly the type to create their own bogus certs. > One could care about CA certificates related to his business, either > well-known or private ones used to verify access to local resources. Of course, but what about a case where you've never heard of them before? Your server asks for a cert, they hand over the only one they have, and you're suddenly wondering how much weight to give it. (See comments above.) > > On a related note, is there documentation on how to set up a "well- > > behaved" certs and PKCS12 bags? I couldn't find anything the last > > time I checked, but maybe something has come out since then. > > Any problem with PKCS12 specifications published by RSA Labs? > What is "well-behaved" ? It's hard to describe "well-behaved" because I rarely use Windows clients, and on Unix I tend to use the locally generated stuff with installers. But I've noticed that instead of loading several items separately, on PCs you often get everything in one package. So the question isn't how to create these packages (I assume the library will hand that), but what to put into them. And as my earlier comment suggests, I'm not even sure if this is a PKCS7 or PKCS12 object - I've been working with X.509 certs (and requests) and PKCS8 keys exclusively. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
