RE: Certificate chaining
> From: owner-openssl-us...@openssl.org On Behalf Of Suresh > Sent: Tuesday, 26 October, 2010 10:41 > Probably I was not clear in my question. > When I have several certificates like server cert + key, intermediate > and root and want all them to bundle in a single file say, PKCS#12. > Is there a specific sequence to bundle them? Not that I know of, but I rarely use nontrivial chains. It might depend on what software will (later) use them. > Please throw some light here. Thanks. > On Thu, Oct 21, 2010 at 11:11 PM, Suresh wrote: > > There is a standard ASN.1 structure, PKCS#7 aka Cryptographic > > Message Syntax or CMS, which can carry multiple certs and/or CRLs > > in DER (or PEM-ified single DER, as opposed to PEM concatenation) > > and is fairly commonly used for that purpose. > This makes me understand PKCS#7 or PKCS#12 can take several > certificates and key in PEM format into a single file. When packaging > server, intermediate and key into a single file is there a sequence to > do that ? I'm not sure if you're asking about the formats or openssl. 7 can't carry (private) keys as such; it can do certs and/or CRLs and/or arbitrary data. (Its design purpose was to carry signed and/or encrypted data, with certs and CRLs as an add-on, but they have become a tail that sometimes wags the dog.) You could write programs that put private key(s) as encrypted data, but nothing else will expect this. 12 can carry (private) keys and certs (but AFAIK not CRLs). openssl pkcs7 doesn't support building, although you could write a program that does. It can read either DER or PEM, and convert to the other, and extract certs into PEM (which another command, openssl x509, can then convert to DER). openssl pkcs12 can build DER from local PEM files (which can have been converted from DER by other openssl commands), or extract DER into local PEM files (which can be converted to DER by other openssl commands). If your goal is to transport a key with the certs needed for it, for example from server-primary to server-backup, or central-keygen to entity, etc., use 12. That's exactly what it was designed for. If you're doing something else, there may be other answers. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate chaining
Probably I was not clear in my question. When I have several certificates like server cert + key, intermediate and root and want all them to bundle in a single file say, PKCS#12. Is there a specific sequence to bundle them? For example: first option = key + server cert + intermediate + root second option = root + intermediate + server cert + key third option = server cert + key + intermediate + root ... Please throw some light here. Thanks. On Thu, Oct 21, 2010 at 11:11 PM, Suresh wrote: > Thank you for a detailed reply Dave. > > > There is a standard ASN.1 structure, PKCS#7 aka Cryptographic > > Message Syntax or CMS, which can carry multiple certs and/or CRLs > > in DER (or PEM-ified single DER, as opposed to PEM concatenation) > > and is fairly commonly used for that purpose. > > This makes me understand PKCS#7 or PKCS#12 can take several > certificates and key in PEM format into a single file. When packaging > server, intermediate and key into a single file is there a sequence to > do that ? > > Also, please correct me if my understanding is correct. > > Thanks. > > On Tue, Oct 19, 2010 at 8:40 PM, Dave Thompson > wrote: > > > > > From: owner-openssl-us...@openssl.org On Behalf Of liv2luv > > > Sent: Tuesday, 19 October, 2010 11:26 > > > > > I am new to SSL and Certificates. > > > > > > I have generated a CSR and certificate for signing. In return > > > I've got three > > > certificates. > > > > > > a. Root CA's certificate > > > b. Intermediate Certificate > > > c. Server certificate > > > > > > After some searching, understand I need to combine them in > > > the sequence as > > > server, intermediate and root certificate. > > > > > Probably not. For an OpenSSL server, you do need entity + > > intermediate as below, unless the/each client has the > > intermediate as trusted (which is sometimes possible). > > > > It rarely makes sense to transmit a root in protocol, > > since the peer must have it already to trust it. > > > > > After that I converted the PEM format to DER to see the > > > certificate. It is > > > only showing the top certificate (server certificate) in this case. > > > > > OpenSSL x509 can look at a certificate file in either DER or PEM > > with exactly the same capabilities. If you mean you had multiple > > certs (e.g. the chain) in one file in PEM format and did > > openssl x509 -inform pem -outform der > > that only converts the first cert found, just like > > openssl x509 -inform pem -text -noout > > only displays the first cert. To process with the commandline > > utility like this you must put each cert in a separate file. > > As to recombining later, see below. > > > > > > > How can the certificate chain be created in a single file? > > > > > There is no standard format for just putting multiple certs, > > or anything else, in DER format into a file. > > > > In a few places OpenSSL accepts multiple certs in PEM format > > in a file. SSL_CTX_load_verify_locations (CAfile), used by > > -CAfile in several utilities, takes certs (and CRLs if used) > > in PEM format in one file. SSL_CTX_use_certificate_chain_file > > takes entity cert plus chain (excluding root, which as above is > > not needed) in PEM format, and thus should be what you need. > > > > This concatenated PEM format is not a standard as far as I know, > > although I believe some others have adopted OpenSSL's method. > > Remember that PEM format (here) is actually just DER encoded > > in base64 plus labels; the "real" data is actually the same. > > > > There is a standard ASN.1 structure, PKCS#7 aka Cryptographic > > Message Syntax or CMS, which can carry multiple certs and/or CRLs > > in DER (or PEM-ified single DER, as opposed to PEM concatenation) > > and is fairly commonly used for that purpose. The SSL routines > > in OpenSSL do not use PKCS#7 directly, although code you write > > using lower-level libcrypto can, and the commandline utility > > pkcs7 can display them from which you can capture them into > > one or more files in PEM format and manipulate further. > > > > > > > > __ > > OpenSSL Project http://www.openssl.org > > User Support Mailing Listopenssl-users@openssl.org > > Automated List Manager majord...@openssl.org > > > > -- > Suresh > -- Suresh
Re: Certificate chaining
Thank you for a detailed reply Dave. > There is a standard ASN.1 structure, PKCS#7 aka Cryptographic > Message Syntax or CMS, which can carry multiple certs and/or CRLs > in DER (or PEM-ified single DER, as opposed to PEM concatenation) > and is fairly commonly used for that purpose. This makes me understand PKCS#7 or PKCS#12 can take several certificates and key in PEM format into a single file. When packaging server, intermediate and key into a single file is there a sequence to do that ? Also, please correct me if my understanding is correct. Thanks. On Tue, Oct 19, 2010 at 8:40 PM, Dave Thompson wrote: > > > From: owner-openssl-us...@openssl.org On Behalf Of liv2luv > > Sent: Tuesday, 19 October, 2010 11:26 > > > I am new to SSL and Certificates. > > > > I have generated a CSR and certificate for signing. In return > > I've got three > > certificates. > > > > a. Root CA's certificate > > b. Intermediate Certificate > > c. Server certificate > > > > After some searching, understand I need to combine them in > > the sequence as > > server, intermediate and root certificate. > > > Probably not. For an OpenSSL server, you do need entity + > intermediate as below, unless the/each client has the > intermediate as trusted (which is sometimes possible). > > It rarely makes sense to transmit a root in protocol, > since the peer must have it already to trust it. > > > After that I converted the PEM format to DER to see the > > certificate. It is > > only showing the top certificate (server certificate) in this case. > > > OpenSSL x509 can look at a certificate file in either DER or PEM > with exactly the same capabilities. If you mean you had multiple > certs (e.g. the chain) in one file in PEM format and did > openssl x509 -inform pem -outform der > that only converts the first cert found, just like > openssl x509 -inform pem -text -noout > only displays the first cert. To process with the commandline > utility like this you must put each cert in a separate file. > As to recombining later, see below. > > > > How can the certificate chain be created in a single file? > > > There is no standard format for just putting multiple certs, > or anything else, in DER format into a file. > > In a few places OpenSSL accepts multiple certs in PEM format > in a file. SSL_CTX_load_verify_locations (CAfile), used by > -CAfile in several utilities, takes certs (and CRLs if used) > in PEM format in one file. SSL_CTX_use_certificate_chain_file > takes entity cert plus chain (excluding root, which as above is > not needed) in PEM format, and thus should be what you need. > > This concatenated PEM format is not a standard as far as I know, > although I believe some others have adopted OpenSSL's method. > Remember that PEM format (here) is actually just DER encoded > in base64 plus labels; the "real" data is actually the same. > > There is a standard ASN.1 structure, PKCS#7 aka Cryptographic > Message Syntax or CMS, which can carry multiple certs and/or CRLs > in DER (or PEM-ified single DER, as opposed to PEM concatenation) > and is fairly commonly used for that purpose. The SSL routines > in OpenSSL do not use PKCS#7 directly, although code you write > using lower-level libcrypto can, and the commandline utility > pkcs7 can display them from which you can capture them into > one or more files in PEM format and manipulate further. > > > > __ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org -- Suresh __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Certificate chaining
> From: owner-openssl-us...@openssl.org On Behalf Of liv2luv > Sent: Tuesday, 19 October, 2010 11:26 > I am new to SSL and Certificates. > > I have generated a CSR and certificate for signing. In return > I've got three > certificates. > > a. Root CA's certificate > b. Intermediate Certificate > c. Server certificate > > After some searching, understand I need to combine them in > the sequence as > server, intermediate and root certificate. > Probably not. For an OpenSSL server, you do need entity + intermediate as below, unless the/each client has the intermediate as trusted (which is sometimes possible). It rarely makes sense to transmit a root in protocol, since the peer must have it already to trust it. > After that I converted the PEM format to DER to see the > certificate. It is > only showing the top certificate (server certificate) in this case. > OpenSSL x509 can look at a certificate file in either DER or PEM with exactly the same capabilities. If you mean you had multiple certs (e.g. the chain) in one file in PEM format and did openssl x509 -inform pem -outform der that only converts the first cert found, just like openssl x509 -inform pem -text -noout only displays the first cert. To process with the commandline utility like this you must put each cert in a separate file. As to recombining later, see below. > How can the certificate chain be created in a single file? > There is no standard format for just putting multiple certs, or anything else, in DER format into a file. In a few places OpenSSL accepts multiple certs in PEM format in a file. SSL_CTX_load_verify_locations (CAfile), used by -CAfile in several utilities, takes certs (and CRLs if used) in PEM format in one file. SSL_CTX_use_certificate_chain_file takes entity cert plus chain (excluding root, which as above is not needed) in PEM format, and thus should be what you need. This concatenated PEM format is not a standard as far as I know, although I believe some others have adopted OpenSSL's method. Remember that PEM format (here) is actually just DER encoded in base64 plus labels; the "real" data is actually the same. There is a standard ASN.1 structure, PKCS#7 aka Cryptographic Message Syntax or CMS, which can carry multiple certs and/or CRLs in DER (or PEM-ified single DER, as opposed to PEM concatenation) and is fairly commonly used for that purpose. The SSL routines in OpenSSL do not use PKCS#7 directly, although code you write using lower-level libcrypto can, and the commandline utility pkcs7 can display them from which you can capture them into one or more files in PEM format and manipulate further. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Certificate chaining
Hi, I am new to SSL and Certificates. I have generated a CSR and certificate for signing. In return I've got three certificates. a. Root CA's certificate b. Intermediate Certificate c. Server certificate After some searching, understand I need to combine them in the sequence as server, intermediate and root certificate. After that I converted the PEM format to DER to see the certificate. It is only showing the top certificate (server certificate) in this case. How can the certificate chain be created in a single file? Thanks for your help! -- View this message in context: http://old.nabble.com/Certificate-chaining-tp3000p3000.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Certificate Chaining
Hi Steve. I think I can help you on this one. Give me a call at 215-538-3535 and ask for Tom Nichols. Steve wrote: > Hello All, > > I have a question regarding the use of certificates in IE 5+ and Netscape > 4.7+. We have written a small customised SSL web server using OpenSSL, > etc... This web server is only to be made available to employees of the > customer company, using SSL to secure the link and a login mechanism to > validate users. > Up until now we have always tested it using a self-signed cert/key pair, but > soon we will be installing it in several customer sites which leads us to > the question: > > Can we apply for a certificate from a CA and us it to sign the certificates > for our customers, ie. can we chain the certificates in a hierarchical > manner? > > If we couldn't do this, what would be the issues to consider about issuing > certificates to our customers signed only by us, bearing in mind that the > trust issue is simpler for us as all parties already have a stronger trust > by being collegues etc... I understand that the browser will bitch a bit > about untrusted certificates but that they can be accepted/trusted after the > first use. > > I would also assume that the certificates of the CA's have been hard-wired > into their EXE's so that installing our certificate into the browser a new > CA is impossible? I'm guessing on this one. > > Any light-shedding would be appreciated, > > TIA, > > Stephen. > > __ > 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]
Certificate Chaining
Hello All, I have a question regarding the use of certificates in IE 5+ and Netscape 4.7+. We have written a small customised SSL web server using OpenSSL, etc... This web server is only to be made available to employees of the customer company, using SSL to secure the link and a login mechanism to validate users. Up until now we have always tested it using a self-signed cert/key pair, but soon we will be installing it in several customer sites which leads us to the question: Can we apply for a certificate from a CA and us it to sign the certificates for our customers, ie. can we chain the certificates in a hierarchical manner? If we couldn't do this, what would be the issues to consider about issuing certificates to our customers signed only by us, bearing in mind that the trust issue is simpler for us as all parties already have a stronger trust by being collegues etc... I understand that the browser will bitch a bit about untrusted certificates but that they can be accepted/trusted after the first use. I would also assume that the certificates of the CA's have been hard-wired into their EXE's so that installing our certificate into the browser a new CA is impossible? I'm guessing on this one. Any light-shedding would be appreciated, TIA, Stephen. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Idiot's summary of [Re: Certificate chaining]
Jan Meijer wrote: > You could have a point here. I was fooling around with a test certificate > that is signed by our root CA (the SURFnet PCA). With this test-certificate > I signed client certs and I had problems verifying the client certs. The > troubles went away after including the PCA certificate in the chain (which > basically tells me openssl does not trust anything unless the final root CA > cert is included. Think I could argue this reasoning ;). Basically our CA > will always put the correct subject line into a client/server cert, as will > the PCA (in a CA's cert). I think it all depends on how the actual clients > and servers handle chain-checking when deciding what might be usefull for > the Openssl verify function to act like. > > I tried to use it when something failed with my netscape browser, and since > that is a pretty closed environment I went to openssl for help. There's the > history of my initial question. Thanks for the answer, I'll have a look at > the docs :) I've just finished sorting out our code and checking with the posts here. Since the above seemed a bit confused (no offence, but this post seems to imply that you knew less than your previous post :-) and since it will help me get things straight in my head, this is a simple summary. If anything contradicts posts from S Henson then believe him - I learnt everything I say here from his posts and playing with our code (home grown Java/C stuff that uses 0.9.4). IF ANYTHING BELOW IS WRONG PLEASE CORRECT ME! Thanks. - I will discuss the case where one party, which I call "client" submits a certificate to another party, which I'll call "server". Those names aren't intended to imply that one party initiated the connection, or that verification will not also occur in the other direction. - So, the client submits a certificate. - The server's aim is to find a self-signed certificate that signed that certificate, or a self-signed certificate that signed a certificate that signed that certificate, or a self-signed certificate that signed a certificate that signed a certificate that... - I'll call the self-signed certificate the "root certificate" and the certificates between it and the client's certificate "intermediate certificates". - All intermediate certificates must be present, but they need not all be present on the server side. The client may supply some intermeditae certificates. This occurs during the SSL handshake. - In my experiments the intermediate certificates were used if they were preent in the client's CAfile or the server's CAfile. Presumable CA directories would also work. - The root certificate must be present on the server - the server will not (successfuly) use a root certificate supplied by the client. - This procedure is open to abuse because you may not trust people that are trusted by people you do trust(!). For example, you may trust A. A may trust B, but you may not trust B. Intermediate certificates can force you to trust B. This is a security hole. - This occurs as follows: You sign A's certificate with your root certificate. A then signs B's certificate with A's certificate. When B connects to your server, B may include A's certificate. Your server will then verify B, using A's certificate as an intermediate certificate. - At the moment (0.9.4) this can be avoided by refusing to accept a depth greater than 1 in the verification process. - Checking the depth is done in our code (and I believe this is normal) within verify_callback. This routine is supplied to SSL using SSL_CTX_set_verify. I can't post our code (sorry), but you would simply return 0 if depth is greater than 1. - This same callback can also be used to implement CRLs. - One way to avoid the problem above is to use the CA flag in basicConstraints. This is a small piece of data within the certificate that indicates whether the certificate is a CA certificate or not (remember that information in the certificate, once signed, cannot be changed, or it will break the signature). - In the past it was recommended that people not bother with this piece of data for compatibility. However, it is need to solve the problem above. - The security hole above can be closed by only signing other people's certificates if the CA flag is false and then checking that all intermediate certificates have a true CA flag. - This allows you to implement a hierarchy of certificates. You can have a root CA whose private key is used to sign some "working CA certificates" (CA flag true) and then hidden away. By keeping the root key off-network and off-site you can be pretty sure that it will not be compromised. - The working CA certificates are used, as intermediate certificates, to sign other people's certificates. But only certificates where the CA flag is false are signed. - Let's return to A and B. A now has a CA=false certificate. A signs B's certificate. B connects, using A's certificate as an intermediate certifi
Re: Certificate chaining
> Check out the docs in the latest snapshot, particularly the verify and > x509 commands. They explain how things operate in the snapshot and > pretty much how 0.9.5 will do things. Thanks. Think I can find the time somewhere this week :) When the organisational reshuffles are over and I'm still working on our CA I'll dive into the code someday. Until then I'm affraid I'm just an ordinary user that needs documentation > That wont happen in 0.9.5. Instead I've concentrated on the fixing the > worst security problems of CA masquerading and lack of trust settings. Now you make me wonder, but I'll ask after reading the snapshot docs. > Having said that I haven't come across a case where the authority and > subject key lookup is actually required because the basic subject lookup > fails to yield the correct certificate. I know its easy to construct > such things but I mean "real world" examples. No doubt I'll now get sent > several... You could have a point here. I was fooling around with a test certificate that is signed by our root CA (the SURFnet PCA). With this test-certificate I signed client certs and I had problems verifying the client certs. The troubles went away after including the PCA certificate in the chain (which basically tells me openssl does not trust anything unless the final root CA cert is included. Think I could argue this reasoning ;). Basically our CA will always put the correct subject line into a client/server cert, as will the PCA (in a CA's cert). I think it all depends on how the actual clients and servers handle chain-checking when deciding what might be usefull for the Openssl verify function to act like. I tried to use it when something failed with my netscape browser, and since that is a pretty closed environment I went to openssl for help. There's the history of my initial question. Thanks for the answer, I'll have a look at the docs :) Jan -- alive=true S/MIME Cryptographic Signature
Re: Certificate chaining
Dr Stephen Henson wrote: > Andrew Cooke wrote: > > However, it seems to me that it would be better if the verifier had only > > the root CA certificate, and the verifiee supplied not just its > > certificate, but the intermediate certs in the chain. In this way, the > > verifier would not need updating if intermediate certs changed (the > > verifiee would have to get new certs anyway, if an intermediate cert was > > revoked). Is this possible? And if not, is there a good reason why not > > (like it's a gaping security hole)? [...] > One thing you have to check is to make sure the chain you get passed > hasn't been illegally "lengthened" by someone using their end user > certificate and private key to masquerade as a CA or possible several > CAs. > > To do this properly you have to check the intermediate certificates > really are CA certificates and do some consistency checking and > workarounds for broken CAs. This is not easy to do. > > Anyway. I've added checks like these and some things like trust settings > to the latest development code. This is quite a hefty change in the way > things are done and it needs extensive testing but all being well > something usable will be in 0.9.5. Does this mean that naieve code that uses OpenSSL is open to this security hole at the moment, or does something have to be done to turn it on? If I supply a chain of certificates as the verifiee's certificate, which includes self-signed, is it detected? I will test this myself, but have just had to reinstall NT (!) and am busy re-installing packages etc, so it won't be for a while yet. Thanks, Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Certificate chaining
Andrew Cooke wrote: > > Hi, > > > However, it seems to me that it would be better if the verifier had only > the root CA certificate, and the verifiee supplied not just its > certificate, but the intermediate certs in the chain. In this way, the > verifier would not need updating if intermediate certs changed (the > verifiee would have to get new certs anyway, if an intermediate cert was > revoked). Is this possible? And if not, is there a good reason why not > (like it's a gaping security hole)? > This has always been possible and it was a gaping security hole. One thing you have to check is to make sure the chain you get passed hasn't been illegally "lengthened" by someone using their end user certificate and private key to masquerade as a CA or possible several CAs. To do this properly you have to check the intermediate certificates really are CA certificates and do some consistency checking and workarounds for broken CAs. This is not easy to do. Anyway. I've added checks like these and some things like trust settings to the latest development code. This is quite a hefty change in the way things are done and it needs extensive testing but all being well something usable will be in 0.9.5. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Certificate chaining
Hi, I've been looking around and can't see an answer to this, but if one exists, please point me to it rather than posting again... I have been playing with certificate chaining (signing certs that are signed by a certificate signed by a certificate signed by ... a self-signed certificate) and have got OpenSSL working with a chain by supplying all the certificates to the code doing the verifying (eg by placing them all in the CA certificate file - I could also have used the hashed directory methods). However, it seems to me that it would be better if the verifier had only the root CA certificate, and the verifiee supplied not just its certificate, but the intermediate certs in the chain. In this way, the verifier would not need updating if intermediate certs changed (the verifiee would have to get new certs anyway, if an intermediate cert was revoked). Is this possible? And if not, is there a good reason why not (like it's a gaping security hole)? Thanks, Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
