Re: CA cert installed/imported but they are not trusted
Sander Temme wrote: On Apr 9, 2010, at 3:02 AM, Götz Reinicke - IT Koordinator wrote: [r...@ldap1 ~]# openssl s_client -connect ldap1.filmakademie.de:389 -showcerts -CAfile /etc/openldap/CA_falu/CA.pem CONNECTED(0003) 5066:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188: What the hell ... hmm. What may be missing/wrong? 389 is plaintext. LDAP-over-SSL runs on 636. S. -- san...@temme.net http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- View this message in context: http://old.nabble.com/CA-cert-installed-imported-but-they-are-not-trusted-tp28179665p28737639.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: How to make a legit CA cert?
This should be more widely understood: an application considers a CA trusted because some human told it so. There is no other way. The recognized CAs are trusted by e.g. your browser because the maker of the browser decided to trust them and so put them into the list of trusted CAs that is packed in the browser. Others have written about the kinds of things those CAs needed to do in order to gain that trust. If you decide that you don't trust one of them, you can take it out and it becomes untrusted *for you*. If you decide to trust a CA that hasn't made the browser makers' goodie lists, you can just install it in your browser's list of trusted CAs and it becomes trusted *for you*. Anyone else can do that too, with a similar result for himself. If any given cert. is calculated to be trusted, that means that, at the top of the chain, it can be linked back to a cert. that someone marked manually as trusted. Trust is not calculable without that. Really, the only thing protecting most people from rogue CAs is the browser makers' understanding that they, too, are in a position of trust, and could be hurt badly by lax acceptance practices no matter how many disclaimers they slather onto the EULA. We should all check and tune our browsers' trust lists. (No, I haven't.) -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Balance your desire for bells and whistles with the reality that only a little more than 2 percent of world population has broadband. -- Ledford and Tyler, _Google Analytics 2.0_ pgp6nnl3aO4Ab.pgp Description: PGP signature
OpenSSL 1.0.0a released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 1.0.0a released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.0a of our open source toolkit for SSL/TLS. This new OpenSSL version is a security and bugfix release which addresses CVE-2010-1633 and CVE-2010-0742. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES. We consider OpenSSL 1.0.0a to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 1.0.0a is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.0a.tar.gz Size: 4015794 MD5 checksum: e3873edfffc783624cfbdb65e2249cbd SHA1 checksum: b837a9f75a51f456bd533690cf04d3d5714812dc The checksums were calculated using the following commands: openssl md5 openssl-1.0.*.tar.gz openssl sha1 openssl-1.0.*.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox Nils Larsch Ulf Möller Ralf S. Engelschall Ben Laurie Andy Polyakov Dr. Stephen Henson Richard Levitte Geoff Thorpe Lutz JänickeBodo Möller -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBTAUWhKLSm3vylcdZAQIdhQgAgVHx3vHjvQbWl4jeOuIC9pJ6sv+0/8ih AK7+FHRi4RL7IfxDG09RYfIlXVgJtGJPjekg8ZfaKiRpK4N9GcGfXYDORC12tMAE wQv9BMvPGqGI3+Pp5eCY2hCyjZCnHsxSvYulKE5WnjD3VJQAtwd+czv3+ToxJ3o1 r9Haj0cRLFDKKzzqYmmm6NfGs8NuZLIQ3Vu2z3O2c3yW8v0yYuTcKYDysLtWsipY pNId06ygM2DL3lIfO5gJSGWV3m9qZzmr4WCBR4qyMcEPMlAiUOxW199tfL4a2L1l 4czRsds7gAKyj7ruJPm+Y0/VQCTt3M8Li4+Z3MQ++Be8/qRmIxC/aw== =fgq3 -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: self-signed SSL certificates and trusted root certificate
--- On Fri, 5/28/10, Dave Thompson dthomp...@prinpay.com wrote: FYI: 'self-sign' in PKI means a *cert* that is signed by its own key, normally only a CA 'root' cert. Thank you for clarifying. Right. They are, and you want to be, another CA. Exactly. So I published MY-CA/cacert.der as shown below. Are your clients only browsers (IE? FF?) or apps? I was testing with IE6 but am now trying out FF 3.5.9. I when to the advanced config options and tried to import the .der file from the Authority tab. FF complains that this is not a certificate authority and cannot be imported. Tried both cacert.der and cacert.pem. So before going any further with server certificates, I guess I need to find out why FF refuses to import my CA certificate. [on CA server] Create CA: # /etc/ssl/misc/CA-HTTP.sh -newca (CA-HTTP.sh is the standard openssl script with custom CATOP path variable) convert to DER # openssl x509 -in MY-CA-HTTP/cacert.pem -outform DER -out MY-CA-HTTP/cacert.der copy it over to a public web server so client browsers can download the DER link and install it to trusted root certificates (mime type application/x-x509-ca-cert) I presume you mean a modified copy of the standard CA.sh . And you chose for your CA name a unique value. Yes, it's a modified copy of CA.sh. The *only* difference is: CATOP=./MY-CA-HTTP unique value for my CA name: are you referring to the CN / Common Name? I guess it is unique. I can name it anything I want, right? (it doesn't need to be a valid host name of a FQDN) I regenerated a new test CA cert and its CN is MY-CA-1. I used a custom openssl.cnf and the only differences with the original file are: dir= ./MY-CA-HTTP # Where everything is kept default_days = 1825 # how long to certify for default_crl_days= 1095 # how long before next CRL 0.organizationName_default = mydomain.org Firefox still refuses to import MY-CA-HTTP/cacert.pem or MY-CA-HTTP/cacert.der. By the way, I'm using openssl 0.9.8k. I'd appreciate any help you can give me. Thanks, Vieri __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
OpenSSL 0.9.8o released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL version 0.9.8o released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.8o of our open source toolkit for SSL/TLS. This new OpenSSL version is a security and bugfix release which addresses CVE-2010-0742. For a complete list of changes, please see http://www.openssl.org/source/exp/CHANGES. We consider OpenSSL 0.9.8o to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 1.0.0a is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-0.9.8o.tar.gz Size: 3772542 MD5 checksum: 63ddc5116488985e820075e65fbe6aa4 SHA1 checksum: 80c73afc7dca790cd26936cb392a4dfd14d4e4d7 The checksums were calculated using the following commands: openssl md5 openssl-0.9.*.tar.gz openssl sha1 openssl-0.9.*.tar.gz Yours, The OpenSSL Project Team... Mark J. Cox Nils Larsch Ulf Möller Ralf S. Engelschall Ben Laurie Andy Polyakov Dr. Stephen Henson Richard Levitte Geoff Thorpe Lutz JänickeBodo Möller -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBTAUjJaLSm3vylcdZAQJjEwf/bzp8+qgnef13+LPMHOayDn4+q880pfhI Ao7kC62xdUr0K3JBetneCNylQQexMg5sgT4KmKqfJo9eit0OdqKG/NOdDN+PMPpQ nXByj1PCJAXeYJkr6OPK5LiK30dVxLUufj7NYGfr01SvqOVLucynX9zRwSgEjDGm 9E+FqI19Nkdul6oNRzTVl4e4VOmAAbcqlVl2qbm6P2IGsfUsQt/cjcAADTKwLc2X 0gHKYzQ4O2CzVPqjbGlhzesbggRUKD4FXlSHGSa9ftO6QSOUBY/+VvaGFTax+Bim AZrW/5jAMZzwRx+DjzqPGV5Mmq7B/WHgYQ8O5VJaHMsekAj6dO1JMw== =VGZO -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
upgrading from 0.9.8l to 1.0
I am starting from a working Axis2c 1.6 / OpenSSL 0.9.8l configuration on Win 2008 R2 server. I am using a debug build and the Windows CRTDBG flags to chase a memory leak of 40K per request, and am hoping that an upgrade to OpenSSL 1.0 will get me out of this spot... I'm so close I can taste it, but right now I am seeing a socket error on the second write. The axis2_http_client_send() method successfully writes some data (253 bytes worth) in its first call to the socket_write() method of bss_sock.c, line 158. It then fails in its next call to write 2 bytes - CRLF - and all I can see is that the writesocket() call in socket_write() returns a -1. Any suggestions on how to proceed? Running openssl s_client -connect my.server.dns:443 -CAfile myCAFile works fine when either openssl version is used by my server. TIA, Steve __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: How to make a legit CA cert?
Thanks Mark, that was an extremely helpful explanation. When I asked this question I was hoping to learn if CA certs are self-signed or if there is some other procedure to authenticate a CA cert as being legitimate. From your explanation it sounds like all CA certs are generated by the CA itself and then its left up to every browser vendor whether or not they want to include a particular CA's cert in its bundle. On Tue, Jun 1, 2010 at 8:19 AM, Mark H. Wood mw...@iupui.edu wrote: This should be more widely understood: an application considers a CA trusted because some human told it so. There is no other way. The recognized CAs are trusted by e.g. your browser because the maker of the browser decided to trust them and so put them into the list of trusted CAs that is packed in the browser. Others have written about the kinds of things those CAs needed to do in order to gain that trust. If you decide that you don't trust one of them, you can take it out and it becomes untrusted *for you*. If you decide to trust a CA that hasn't made the browser makers' goodie lists, you can just install it in your browser's list of trusted CAs and it becomes trusted *for you*. Anyone else can do that too, with a similar result for himself. If any given cert. is calculated to be trusted, that means that, at the top of the chain, it can be linked back to a cert. that someone marked manually as trusted. Trust is not calculable without that. Really, the only thing protecting most people from rogue CAs is the browser makers' understanding that they, too, are in a position of trust, and could be hurt badly by lax acceptance practices no matter how many disclaimers they slather onto the EULA. We should all check and tune our browsers' trust lists. (No, I haven't.) -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Balance your desire for bells and whistles with the reality that only a little more than 2 percent of world population has broadband. -- Ledford and Tyler, _Google Analytics 2.0_ __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: self-signed SSL certificates and trusted root certificate
From: owner-openssl-us...@openssl.org On Behalf Of Vieri Sent: Tuesday, 01 June, 2010 10:25 --- On Fri, 5/28/10, Dave Thompson dthomp...@prinpay.com wrote: Are your clients only browsers (IE? FF?) or apps? I was testing with IE6 but am now trying out FF 3.5.9. I when to the advanced config options and tried to import the .der file from the Authority tab. FF complains that this is not a certificate authority and cannot be imported. Tried both cacert.der and cacert.pem. So before going any further with server certificates, I guess I need to find out why FF refuses to import my CA certificate. I think I found it, and it's an extension in the CA cert. I normally use (by hand) the one-step way (req -new -x509) rather than the two-step sequence used by CA.sh (req -new then ca -selfsign). My custom config has no extensions and produces v1, which FF likes, but two-step with standard config used [usr_cert] extensions which has basicConstraints=CA:false. The standard config file has a [v3_ca] section intended for CA cert(s) with CA:true, so it looks like the minimal fix is: on the $CA invocation at line 92+ add -extensions v3_ca . CA.pl has that, and so does CA.sh in 0.9.8m+ and 1.0.0b4+ (and also like CA.pl -create_serial instead of write serial, but still not write crlnumber). (And in both asking for a 'certificate' when we actually want a key if existing, is poor.) I use multiple config files, and editing my CA config and doing two-step makes FF (3.5.9) happy (as does my one-step), but that editing would be a pain with standard single config. Amazingly IE7 on testing likes even CA:false, which is crazy. Although knowing M$ there may be a registry setting somewhere -- or a dozen -- that it's not worth my time to track down. I may try to dig up an old machine still on IE6 and see if that is (was) any different/better. And you chose for your CA name a unique value. unique value for my CA name: are you referring to the CN / Common Name? I guess it is unique. I can name it anything I want, right? (it doesn't need to be a valid host name of a FQDN) I regenerated a new test CA cert and its CN is MY-CA-1. Actually the full Distinguished Name aka DN, which can contain country,state,province,org,orgunit(s),CN, and even other items if supported by the using parties, although CN unique is sufficient to make DN unique. DN definitely shouldn't be the same as any other CA you or your clients trust (or will). This isn't likely to happen by accident, but I just wanted to make sure you hadn't thought it would work to impersonate Verisign or somesuch, or perhaps have a (test) system with data left from another test that chose the same (perhaps convenient) test names. In theory (all?) DN fields can be BMP (approximately Unicode) but AFAICS openssl doesn't make that convenient, and other tools may not either, so IMHO you should limit to ASCII printable, plus avoid characters commonly used in notating DNs (mostly slash, equals, quote, sometimes comma) to avoid confusion. CN doesn't need to be hostname or domainname for a CA cert. Technically not required on entity cert either, but on WWW most parties do want/like entity's CN to be domainname. I used a custom openssl.cnf and the only differences with the original file are: dir= ./MY-CA-HTTP # Where everything is kept default_days = 1825 # how long to certify for default_crl_days= 1095 # how long before next CRL 0.organizationName_default = mydomain.org Fine. Personally I wouldn't put a domainname in organization, but technically it should work. Doing CRLs valid for 3 years would be silly, but I assume you're not actually doing CRLs at all and this is just ignored. By the way, I'm using openssl 0.9.8k. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Client cert verification SSL_CTX_set_client_CA_list()
Hi All, Could someone help me understand why there is a function SSL_CTX_set_client_CA_list() for telling the client which CAs the server will recognize but no function for telling the server which CAs the client will recognize? In other words, could you please explain the asymmetry? It doesn't make a whole lot of sense to me. Whether a client or server I give the same cert bundle file argument to SSL_CTX_load_verify_locations(). It seems like the latter function should be sufficient in determining which CAs are recognized. Thanks, Dallas __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl req command
Dave Thompson dthomp...@prinpay.com wrote in message news:ee558ada74ef4896a656a182b39d9...@prinpay.com... From: owner-openssl-us...@openssl.org On Behalf Of Jamrock Sent: Sunday, 30 May, 2010 06:35 In the past I have created my certificates as follows: /etc/pki/tls/misc/CA -newca openssl req -newkey rsa:2048 -nodes -keyout newreq.pem -out newreq.pem /etc/pki/tls/misc/CA -sign The /etc/pki/tls/misc/CA script has a -newreq option. $REQ -new -keyout newkey.pem -out newreq.pem $DAYS. This appears to put the key and the certificate in different files. The command I use appears to put the key and the certificate in a single file. What are the advantages and disadvantages of each approach? I guess/hope /etc/pki/tls/misc/CA is a copy (possibly modified) of or link to openssl's apps/CA.sh; assuming so: Your method puts the Certificate Signing *Request* aka CSR and (unencrypted!) privatekey in one file. CA.sh -sign does openssl ca -policy policy_anything -out newcert.pem -infiles newreq.pem so the *certificate* is in newcert.pem, and that's the (other) file you must give your application to use for this identity. In a real CA situation, where you send the CSR off somewhere to get a cert, you absolutely must not send your unencrypted private key, and having it in the same file risks that mistake. Even post-editing might not work; while no CA I've heard of uses MSWord files or PDF, if for example you paste your key+req into a vanilla HTML form and delete the key and then POST you're okay, but if that HTML used some 'helpful, convenient' scripting to 'make things better for the customer', or just to 'keep advertising annoyingly at every opportunity', it could easily have stored your key somewhere that later gets exposed. If you're careful pasting and your finger doesn't slip you can avoid this, but with separate files you don't have to worry. If you encrypted your privatekey, as is better practice, then there would be somewhat less security risk in sending it out, but still some since it's only protected by a human-memorable passphrase which almost never contains the 80ish bits of entropy needed nowadays (and likely more in the future). Plus it could confuse the CA, depending on the CA. But for your own CA like this there's no security issue, and 'openssl ca' in particular isn't confused by this format. Also, it is technically possible to create multiple CSRs and thus obtain multiple certs for the same key(pair), although I have never seen a desirable use-case. If you did do this, putting the CSRs in separate files would allow you to give them descriptive, necessarily different, filenames, which be a good idea in dealing with a situation that could easily be(come) confusing. (And the same for the certs.) Thanks for the explanation. I will test using 2 separate files. The CA script is CentOS's version of the CA.sh script. The name was changed a version or so ago. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
printing a certificate
Hi,
Would someone kindly tutor me on how to print out a certificate
programmatically? I know how to extract the common name, but was just
wondering if there is an API function to just print the whole thing in
human readable form?
X509 *pX509Peer = SSL_get_peer_certificate( pSsl );
if ( pX509Peer != 0 )
{
// Extract the common name from the peer's certificate
X509_NAME_get_text_by_NID( X509_get_subject_name( pX509Peer ),
NID_commonName, commonName,
commonNameBufferSize );
Thanks,
Dallas
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
