[openssl.org #1364] index.txt corruptions
This bug is affecting us as well. It seems to be prevalent during generation of several certificates at the same time, leading me to think it is a race condition. There is no evidence supporting it is a bug occuring every X certificates. Rather, as stated, it shows itself during multiple certificate generation. http://bugs.cacert.org/view.php?id=202 is another occurence of this bug, and contains some discussion. However, the patch offered seems a bit hacky. I see that this has been open (indeed, new) since 2007. Has no headway been made? Thanks, Adam __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: What are the procedures to authenticate certificate?
Hi all, To properly validate the certificate, the steps in RFC5280 Section 6 need to be followed. This allows for validation of the certificate, as well as the chain back to a trusted Root. OpenSSL 1.0.1 has most of the pieces in place to do this, but there are a few areas where you would need to supplement this with additional code, specifically surrounding obtaining and evaluating the revocation information. Doing this properly and efficiently can be a bit tricky (especially in high volume environments), but there exists tools like Pathfinder (http://www.carillon.ca/tools/pathfinder) that can handle this for you. Have fun. Patrick. On 2013-04-10, at 9:28 PM, Salz, Rich wrote: The proper term is proof of possession. SSL/TLS define how to do it in the protocol spec. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org --- Patrick Patterson Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: What are the procedures to authenticate certificate?
There are a number of concepts that are related, but they are different, and it (can be) important to keep them straight. Proof of possession -- how do you know that someone who gave you a cert has the private key? This seems to be what the OP was writing about. Conceptually, you give them something to encrypt with the private key and you decrypt it with the public key. Certificate verification -- does the signature on the certificate work, is it within the validity period? Conceptually, basic math :) Certificate validation -- Was the certificate not revoked? More complicated, with OCSP and CRL's and such; note the phrasing of the previous sentence -- that's deliberate. Path validation -- was the certificate signed by someone you trust? If you can't answer that question, recurse -- was their certificate signed by someone you trust, and so on. And were the signers doing things within the policies allowed by their signer? (For example, you should reject a cert signed by someone who doesn't have the CA bit enabled in their certificate.) And can you verify the signer's certificate? Gets more complicated as the certificate chains get longer. Conceptually, this is the more theoretical part of PKI and also a major barrier to deployment. Note that Certificate validation can also include application-oriented issues. For example, in HTTP-over-SSL, the name in the server's certificate must match the website you are connecting to. Looking at fields like the commonName part of the subjectDistinguishedName, and the subjectAltName extension. Hope this helps. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2051] [PATCH] IPv6 support for s_client and s_server
On Wed, 10 Apr 2013, Michael Tuexen wrote: The main point is whether the OpenSSL maintainers are interested in IPv6 support or not. If they are, the patch can be optimized in whatever way they want. I they are not, the patch goes nowhere, so optimizing it doesn't make much sense... Best regards Michael I would love it if the maintainers would actually come forward and give a direct answer on whether or not they're interested. -- Station! -Bill Ted's Bogus Journey Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2051] [PATCH] IPv6 support for s_client and s_server
--On Thursday, April 11, 2013 9:37 AM -0700 Dan Mahoney, System Admin d...@prime.gushi.org wrote: I would love it if the maintainers would actually come forward and give a direct answer on whether or not they're interested. +1 --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2051] [PATCH] IPv6 support for s_client and s_server
On Thu, Apr 11, 2013, Quanah Gibson-Mount wrote: --On Thursday, April 11, 2013 9:37 AM -0700 Dan Mahoney, System Admin d...@prime.gushi.org wrote: I would love it if the maintainers would actually come forward and give a direct answer on whether or not they're interested. +1 Well I'm interested, though I'm a bit overwhelmed with other things ATM to look at the patch in any detail. Note that due to the versioning scheme the earliest this could appear in a release in 1.0.2. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #2051] [PATCH] IPv6 support for s_client and s_server
Is there a target date for releasing 1.0.2? Thanks, Paul -Original Message- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Thursday, April 11, 2013 11:06 AM To: openssl-dev@openssl.org Subject: Re: [openssl.org #2051] [PATCH] IPv6 support for s_client and s_server Well I'm interested, though I'm a bit overwhelmed with other things ATM to look at the patch in any detail. Note that due to the versioning scheme the earliest this could appear in a release in 1.0.2. Steve. -- The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: change in x509 -CA in 1.0.1?: doesn't encode new Issuer
From: owner-openssl-us...@openssl.org On Behalf Of Salz, Rich Sent: Tuesday, 09 April, 2013 12:55 -dev added, I think this is a bug This pair of commands used to work as expected, but in 1.0.0 and later the resulting cert is self-signed, and not signed by the CA key. ITYM 1.0.1 as per subject. openssl req -x509 -days 999 -keyout req.key -out req.pem \ -subj /CN=testme -nodes -new -newkey rsa:2048 req -new -x509 should and does produce a selfsigned cert. (Do you really want both self-signed AND CA-signed? If not you could just do req -new and x509 -req.) openssl x509 -in req.pem -CA cacert.pem \ -CAkey cakey.pem -set_serial 1234 -out cert.pem Here I get correct result in 1.0.0 but wrong in 1.0.1. The signature is in fact under the CA key per rsautl, but the Issuer field does not identify the CA as it should, it still equals Subject falsely indicating selfsigned. This occurs even though x509_certify in apps/x509.c did change x-cert_info-issuer. I suspect this may be asn1 using a cached encoding when it shouldn't, but the code is convoluted enough I can't figure out where to debug. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2051] [PATCH] IPv6 support for s_client and s_server
Thanks Steve for showing interest on this. And I think we could start another thread discussing this patch and improving it. Regards, Bala