RE: How to include intermediate in pkcs12?
A lot of things on the Internet are wrong. The OpenSSL man page does not say multiple occurrences work and I'm pretty sure it never did, nor did the code. In general OpenSSL commandlines don't handle repeated options; the few exceptions are noted. pkcs12 -caname (NOT -cafile) IS one of the few that can be repeated, and possibly some things on the Internet got that confused. However, the commandlines (at least usually?) don't *diagnose* repeated (and overridden) options. pkcs12 -export gets certs from up to three places: - the input file (-in if specified else stdin redirected or piped) - -certfile if specified (once, as you saw) - the truststore if -CAfile and/or -CApath specified IF NEEDED In other words, any cert in infile or certfile is always in the output, needed or not. If that set does not provide a complete chain, pkcs12 will try to complete it using the truststore if specified, but will produce output even if it remains incomplete. Like other commandlines, and many programs using the library, the truststore can be a single file with -CAfile (NOT -cafile) or a directory of hashnamed links or files with -CApath or both. If the cert you are putting in pkcs12 is under a CA that you trust other peers to use and thus you have in your truststore, easiest to use it from there. Similarly if your cert is under an intermediate (or several) that you have in your truststore to allow peers to use even if the peers don't send (as they should), easiest to use from there. Otherwise IMO it's easiest to just put in infile or -certfile (or a combination), although the option of temporarily creating or modifying a truststore works. Whether to do your trustore with CAfile or CApath or both is a more general question and depends partly on whether you use somebody's package. For example the curl website supplies the Mozilla truststore in CAfile format; when I want to use that I don't bother converting to CApath format. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Edward Ned Harvey (openssl) Sent: Tuesday, April 22, 2014 15:31 To: openssl-users@openssl.org Subject: *** Spam *** How to include intermediate in pkcs12? A bunch of things on the internet say to do -cafile intermediate.pem -cafile root.pem or -certfile intermediate.pem -certfile root.pem and they explicitly say that calling these command-line options more than once is ok and will result in both the certs being included in the final pkcs12... But I have found this to be untrue. I have found, that if I concatenate intermediate root into a single glom file, and then I specify -certfile once for the glom, then my pfx file will include the complete chain. But if I use -certfile twice, I get no intermediate in my pfx. And I just wasted more time than I care to describe, figuring this out. So... While concatenation/glom is a viable workaround, I'd like to know, what's supposed to work? And was it a new feature introduced after a certain rev or something? I have OpenSSL 0.9.8y command-line on Mac OSX, and OpenSSL 1.0.1e command-line on cygwin. I believe I've seen the same behavior in both.
RE: How to include intermediate in pkcs12?
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Dave Thompson - the truststore if -CAfile and/or -CApath specified IF NEEDED Thank you very much for your awesome detailed answer. This answers a lot of questions, but I am left with a new one: I use openssl on a lot of different platforms, and it always seems to be built differently... OSX native, OSX homebrew, various linuxes, openindiana, cygwin, nuGet in Visual Studio, etc. I don't know if these builds universally include any set of root CA's, and sometimes I can find a directory to answer my question, sometimes not. Is there some way I can make openssl tell me the list of roots it has? Or tell me the directory (directories) that it searches? It seems, to answer my original question, *if* I can trust that openssl on the platform that I'm using actually as a complete-ish set of root CA's, then the best and easiest way to build the pfx will be: openssl pkcs12 -export -out mypkcs12.pfx -inkey my.private.key -in mycert.crt -certfile intermediate.crt (Correct?) And if the above doesn't automatically include the root CA for my chain (or if I just like doing it explicitly), then I can do this: openssl pkcs12 -export -out mypkcs12.pfx -inkey my.private.key -in mycert.crt -certfile intermediate.crt -CAfile ca.crt (Correct?) Alternatively, I could cat mycert.crt intermediate.crt ca.crt mychain.crt openssl pkcs12 -export -out mypkcs12.pfx -inkey my.private.key -in mychain.crt (Correct?) Thanks... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL Root CA and Intermediate CA Certs.
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Edward Ned Harvey (openssl) Sent: Wednesday, 23 April, 2014 21:05 Subject: RE: SSL Root CA and Intermediate CA Certs. I don't know how you learn about SSL/TLS, other than (a) reading the internet, Man, I *tried* to read the Internet, but to be honest I got bogged down somewhere around 2.0.0.0. (b) taking some courses on general cryptography (there is a free online course at coursera.com, which is quite good.) and (c) the thing that I actually found the most useful, a general book on cryptography called Cryptography Engineering I'd argue that knowing about cryptography, and especially about implementing cryptography, is not very helpful for understanding SSL/TLS. Once you understand the purpose of the primitives - symmetric and asymmetric encryption, message digests, and digital signatures - the details don't help you with the SSL/TLS protocols themselves, or even with choosing cipher suites. (While some suites are vulnerable to particular attacks, you can take the word of crypto experts on those points and weigh them against your threat model. Understanding the specifics of the threat isn't necessary.) And understanding the details of cryptographic implementation won't help at all with PKI. So I'd suggest starting with a quick cryptography primer that covers the primitives, and then something like Rescorla's /SSL and TLS/ book. It's not an exciting read, but then SSL/TLS is not an exciting subject. For someone who does want more background in cryptography, I'd recommend Schneier's /Applied Cryptography/ over /Cryptography Engineering/. The latter is for people implementing cryptography, which beginners should never do. As a rule of thumb, don't attempt to implement cryptography until you know when it's appropriate to violate this rule. And as Schneier himself has pointed out numerous times, cryptography isn't the problem, or the solution, anyway. (If you think cryptography is the solution to your problem, you don't understand cryptography and you don't understand your problem.) How and why do you trust any root certs? Generally they're built-in to your OS or your browser, so you're just blindly trusting that those guys know what they're doing. And they don't, and they don't care that they don't. The SSL/TLS X.509-with-well-known-CAs PKI is fundamentally broken and frequently compromised. But there's little we can do about it, so we pretend it isn't. Of course the point of *any* security system is to raise the work factor for attackers until the cost of breaking the system is greater than the return for breaking it, under your threat model. SSL/TLS raises that cost over unencrypted communications. But it doesn't raise it nearly as much as it ought to, thanks to broken protocols, broken implementations, broken PKI, mismanagement, and user error. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com
RE: SSL Root CA and Intermediate CA Certs.
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Michael Wojcik For someone who does want more background in cryptography, I'd recommend Schneier's /Applied Cryptography/ over /Cryptography Engineering/. The latter is for people implementing cryptography, which beginners should never do. Huh - I thought Cryptography Engineering was the 3rd edition of Applied Cryptography, renamed. But now I look at it, it seems you're right, it's a different book entirely. However, I never got the impression that Cryptography Engineering was meant for people implementing new algorithms or anything like that. They very roundly and repeatedly beat into you, don't do that, without loads and loads of courses in mathematics, and a thoroughly vetted public and expert review process. (Such as AES/SHA, etc). They do a nice round job of covering the basics, describing what a block cipher is, what a hash algorithm is, PKI, symmetric/asymmetric, etc, what the characteristics are, how to think about threat models, and how to use these things in the ways that they're intended to be used, etc. So don't discount Cryptography Engineering, but definitely consider Applied Cryptography in addition, or instead.
Re: SSL Root CA and Intermediate CA Certs.
On Thu, Apr 24, 2014 at 12:57:36PM +, Michael Wojcik wrote: [snip] How and why do you trust any root certs? Generally they're built-in to your OS or your browser, so you're just blindly trusting that those guys know what they're doing. And they don't, and they don't care that they don't. The SSL/TLS X.509-with-well-known-CAs PKI is fundamentally broken and frequently compromised. But there's little we can do about it, so we pretend it isn't. Well, there certainly is something we can do about it, but you won't like it any more than I do: 1. Empty all of your trust stores. 2. Add the cert.s of all CAs you already trust (if any) to your trust stores. 3. Investigate each CA you don't yet trust. As you come to trust one, add it to your trust stores. 4. Pay attention to the CAs you trust, and evict any that seem to have declined to a degree that worries you. 5. Goto 3. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
patch available for CVE-2010-5298?
Thanks!
Re: How to include intermediate in pkcs12?
On Apr 24, 2014, at 8:21 AM, Edward Ned Harvey (openssl) open...@nedharvey.com wrote: From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Dave Thompson - the truststore if -CAfile and/or -CApath specified IF NEEDED Thank you very much for your awesome detailed answer. This answers a lot of questions, but I am left with a new one: I use openssl on a lot of different platforms, and it always seems to be built differently... OSX native, OSX homebrew, various linuxes, openindiana, cygwin, nuGet in Visual Studio, etc. I don't know if these builds universally include any set of root CA's, and sometimes I can find a directory to answer my question, sometimes not. OpenSSL itself does not include any certificates at all. The root certificates installed on a system are unrelated to the version of OpenSSL or how OpenSSL was compiled. Is there some way I can make openssl tell me the list of roots it has? Or tell me the directory (directories) that it searches? For the second question, no; there’s no location that OpenSSL (either the library or the command line app) will search automatically — you have to specify that on your own, with -CApath (or -CAfile). For the first question, there are a few different possibilities, but remember that you have to tell OpenSSL where to look, and what to look for. :) You could, e.g., use ‘openssl x509 -noout -text -in file’ for a bunch of different certificate files in DER or PEM format (it’ll even work if there are multiple certificates in file). It seems, to answer my original question, *if* I can trust that openssl on the platform that I'm using actually as a complete-ish set of root CA's, then the best and easiest way to build the pfx will be: openssl pkcs12 -export -out mypkcs12.pfx -inkey my.private.key -in mycert.crt -certfile intermediate.crt (Correct?) If the OS has a complete-ish set of root certificates installed somewhere, you can use a command line like that, but you probably want to use -CApath to specify the directory where the root certificates are installed. And if the above doesn't automatically include the root CA for my chain (or if I just like doing it explicitly), then I can do this: openssl pkcs12 -export -out mypkcs12.pfx -inkey my.private.key -in mycert.crt -certfile intermediate.crt -CAfile ca.crt (Correct?) That’s likely to be more reliable everywhere. :) Alternatively, I could cat mycert.crt intermediate.crt ca.crt mychain.crt openssl pkcs12 -export -out mypkcs12.pfx -inkey my.private.key -in mychain.crt (Correct?) This would also work, but unless you’ve got another reason to stick all of the certificates in the chain into a single file first, it’s likely to be more trouble than it’s worth. I usually put my root and any intermediates into a single file and use -CAfile to specify the intermediate(s) (if any) and root when I’m generating certificates and packaging them in PKCS#12 for distribution (e.g. to send to a Windows user). But I think the question of what’s “best” is dependent on what you’re doing, and how you like to do things. :) TOM Thanks... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: How to include intermediate in pkcs12?
From: owner-openssl-us...@openssl.org [mailto:owner-openssl- us...@openssl.org] On Behalf Of Tom Francis openssl pkcs12 -export -out mypkcs12.pfx -inkey my.private.key -in mycert.crt -certfile intermediate.crt -CAfile ca.crt (Correct?) So ... I just tried this, and confirmed, that it doesn't work... The root CA cert is not included in the pfx. Alternatively, I could cat mycert.crt intermediate.crt ca.crt mychain.crt openssl pkcs12 -export -out mypkcs12.pfx -inkey my.private.key -in mychain.crt It seems the easiest thing to do is... cat intermediate.crt ca.crt chain.crt openssl pkcs12 -export -out mypkcs12.pfx -inkey my.private.key -in mycert.crt -certfile chain.crt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: patch available for CVE-2010-5298?
On Thu, Apr 24, 2014 at 1:49 PM, Bin Lu b...@juniper.net wrote: Thanks! Ben Laurire checked it in recently (within the last week or so). Until it makes it way into the the tar balls, I believe you should try: https://rt.openssl.org/Ticket/Display.html?id=2167user=guestpass=guest. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
