Re: Certificate with multiple CN fields - valid?
Valid is whatever browser understands. As X.509 is/was related to LDAP, then having multiple cn's in an entry is a no-no. -- Konrads Smelkovs Applied IT sorcery. On Wed, Jun 2, 2010 at 5:23 AM, John Nagle na...@sitetruth.com wrote: Normally, when a certificate is to be valid for more than one domain name, one name is in the CN field, and the others are in the subjectAltName extension. But look at the cert for https://www.ipmirror.com/;. It has CN = admincms.ipmirror.com CN = business.ipmirror.cn CN = business.ipmirror.com CN = business.ipmirror.de CN = business.ipmirror.jp CN = business.ipmirror.kr CN = chat.ipmirror.com CN = customer.ipmirror.cn CN = customer.ipmirror.com CN = customer.ipmirror.de CN = customer.ipmirror.jp CN = customer.ipmirror.kr CN = demo-business.ipmirror.com CN = demo-customer.ipmirror.com CN = imap.ipmirror.com CN = netrunner.ipmirror.com CN = ote-business.ipmirror.com CN = ote-customer.ipmirror.com CN = ote-rapi.ipmirror.com CN = ote-registryconsole.ipmirror.com CN = rapi.ipmirror.com CN = rapiote.ipmirror.com CN = rcube.ipmirror.com CN = register.ipmirror.de CN = registryconsole.ipmirror.com CN = telhosting.ipmirror.com CN = www.ipmirror.com This was issued by CN = PositiveSSL CA O = Comodo CA Limited L = Salford ST = Greater Manchester C = GB Validity dates are (1/6/2010 0:00:00 AM GMT) to (7/10/2010 23:59:59 PM GMT) so it's a currently live cert from a major CA. The cert chain validates properly. Is this considered valid? John Nagle __ 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?
As somebody who audits CAs for purpose of them getting into trusted root list, this is what you have to do: a) Obtain WebTrust for certification authorities or ETSI 101 456 standard (+ EV guidelines from cabforum.org) b) Implement systems in line with one of these standards. Not cheap. HSM devices alone cost $10k upwards. c) Get somebody who is trustworthy (think accountants or one of Big 4 auditor companies, i recommend KPMG as I work for them) and/or webtrust accredited auditors (who can certify) to audit you. First time you will almost fail, but if the auditor is an advisor, he'll help you through. Not a cheap thing to do either. d) Submit your application to microsoft trusted root list program, mozilla, opera and everybody else. MS has deadlines on march and september for submission e) Every 12 months, repeat audit. f) Ask yourself, do you really need it and get maybe some CA to cross sign you. -- Konrads Smelkovs Applied IT sorcery. On Sat, May 29, 2010 at 5:08 AM, Patrick Patterson ppatter...@carillon.cawrote: On 28-May-10, at 8:04 PM, Dallas Clement wrote: This is probably a dumb question, but if I wanted to be come the next Verisign of this world, how do I create a legitimate CA cert? I'd like to be able to create my own that passes verification without throwing errors, like unknown CA. Well, the first thing that you do, is do things that build Trust, or the perception that you are trustworthy. Invest in hardware that will protect the CA's keys. Build processes that protect those keys. Use facilities that give the impression of trust (if you've ever been to Verisign HQ for a key ceremony, you'll appreciate the amount of theater that they do :). Then, document all of these in your Certificate Policy and Certification Practice Statement, along with all of the ways that you go about binding people or servers to their associated keys, and how you manage all of your personnel and facilities that are used in the operation of the CA, and issuance of certificates by that CA. When you cut your keys, do it in the presence of an auditor, and according to a proper key ceremony script. Once you have this, then get audited to prove that you are following your certificate policy. Most of the browser vendors, to be included in their Trusted Roots list, like to see a Webtrust audit. If you want to be included in the list that can validate EVSSL certs, then you have to also follow the guidelines of the CA/Browser forum. Most of the vendors, however, also have the caveat that in order to be included in their list, you have to be a commercial entity that are issuing certs to John Q Public. If you only issue to people within a small, closed community, then you'll have to talk pretty fast to get them to accept your CA into their browser. That's it. If you need any help, give us a call :) --- Patrick Patterson President and Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: handshake failure / SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr
Make sure that the client and the server can use same suite of ciphers. -- Konrads Smelkovs Applied IT sorcery. On Thu, Apr 1, 2010 at 3:34 PM, Götz Reinicke - IT-Koordinator goetz.reini...@filmakademie.de wrote: Hi, this drives my crazy for about two days: I do have two virtual Red Hat El 5.4 servers in a test environment. One should be an openldap master, the second should be a openldap slave. openssl-0.9.8e-12.el5_4.1, openldap-2.3.43-3.el5 (RH EL original rpms) I followed some instructions to set up TLS: Set up a CA, generate/sign certificates and keys, install tham on the servers and configure openldap, restart. My problem is: tls works on the master (which also is my CA for the test), but not on the slave. I've openssl verifyed and openssl x509 -texted the certs - everything seams o.k. I've checked ip addresses, name resolving, locations, pathes, permissions, fileversions - anything I can think of. I've regenerated the key and cert for the slave following an other documentation (at least with the same steps), but alway do get the same error: from the ldap server debug: TLS trace: SSL3 alert write:fatal:handshake failure TLS trace: SSL_accept:error in SSLv3 read client hello B TLS trace: SSL_accept:error in SSLv3 read client hello B TLS: can't accept. TLS: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr.c:975 connection_read(13): TLS accept failure error=-1 id=0, closing from the ldap client debug: TLS trace: SSL3 alert read:fatal:handshake failure TLS trace: SSL_connect:error in SSLv2/v3 read server hello A TLS: can't connect. ldap_perror ldap_start_tls: Connect error (-11) additional info: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure May be I missed a step or still skiped something ... A thousand kowtows for any helping hint...!! Best regards, Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reini...@filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Geschäftsführer: Prof. Thomas Schadt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: 4485:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:148:
Hi, This issue also spurred me to think about a patch :) I don't think OpenSSL should write a RFC 2560 noncompliant feature, however, an option would be to provide a warning explaining the issue better than current OCSP_basic_verify:root ca not trusted and then optionally doing the extra steps to verify up the chain. -- Konrads Smelkovs Applied IT sorcery. On Wed, Mar 24, 2010 at 2:38 PM, Rob Stradling rob.stradl...@comodo.comwrote: On Wednesday 24 March 2010 12:01:51 you wrote: snip Well it would typically require giving a public responder access to a CA key: increasing the risk of compromise especially if the private key itself is placed on the server. Steve, I think it's entirely unfair to label the non-delegated model as not recommended for security reasons just because *some implementations* might give a public responder access to a CA key. snip Yes sorry I should've qualified that statement. I was attempting to keep this simple and that always includes the risk of oversimplification. Steve, thanks for explaining. snip Though of course the delegated trust model can also support pre-produced OCSP responses. That's true. By the way Steve, I'd like to propose a small change to openssl ocsp to support the non-delegated model more seamlessly. I've always been surprised and slightly confused that you have to specify both -issuer ca.pem and - VAfile ca.pem to verify the signature on a non-delegated OCSP Response. Why doesn't -issuer ca.pem cause ca.pem to be treated as a candidate OCSP Response signer certificate? When, a couple of weeks ago, a colleague independently made the same observation and asked me that same question, it spurred me to write a patch. Would you be happy with this change in behaviour? If so, I'll submit my patch to the Request Tracker. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org Rob Stradling Senior Research Development Scientist C·O·M·O·D·O - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
4485:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:148:
Hello, I am running OpenSSL 0.9.8g 19 Oct 2007. I have a certificate for which I want to check OCSP response. Root chain is added to root list. OpenSSL says all of it is OK: Chain has three level architecture - Root which Signs OCSP Policy, Policy which signs issuing CA which signs subscriber CA. $ openssl verify ksmelkovs.pem # Cert to verify ksmelkovs.pem: OK $ openssl verify tssp.pem # OCSP responder cert tssp.pem: OK $ openssl verify cacers/*vas*rca*pem cacers/vas latvijas pasts ssi(rca).pem: OK $ x509 ksmelkovs.pem -text |grep ocsp OCSP - URI:http://ocsp.e-me.lv/responder.eme $ x509 ksmelkovs.pem -text |grep Issue Issuer: C=LV, O=VAS Latvijas Pasts - Vien.reg.Nr.40003052790, OU=Sertifikacijas pakalpojumi, CN=VAS Latvijas Pasts SI(CA2) $ ocsp -issuer cacers/*ca2*pem -cert ksmelkovs.pem -url http://ocsp.e-me.lv/responder.eme *Response Verify Failure 5083:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:148: *ksmelkovs.pem: good This Update: Mar 23 11:29:33 2010 GMT konr...@konrads-laptop:~/Sertifikati$ openssl verify ksmelkovs.pem ksmelkovs.pem: OK Copies of these certs are uploaded here: http://drop.io/lykqq21# The 64k USD question: If I have entire trust chain in trusted list, then why would it complain? -- Konrads Smelkovs Applied IT sorcery.
Re: 4485:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:148:
Hi, The OCSP responder has EKU=OCSP: X509v3 extensions: X509v3 Subject Key Identifier: 2B:6E:08:08:9D:92:5A:59:CB:BB:46:89:77:E8:A0:17:47:82:88:5C X509v3 Extended Key Usage: OCSP X509v3 Key Usage: Digital Signature, Non Repudiation X509v3 Authority Key Identifier: keyid:CC:C3:F5:66:FF:73:AC:38:5A:96:1B:21:89:B8:81:4C:1F:CB:5E:25 I attached OCSP cert. I believe this is setup #2 you described. -- Konrads Smelkovs Applied IT sorcery. On Tue, Mar 23, 2010 at 5:39 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Tue, Mar 23, 2010, Konrads Smelkovs wrote: Hello, I am running OpenSSL 0.9.8g 19 Oct 2007. I have a certificate for which I want to check OCSP response. Root chain is added to root list. OpenSSL says all of it is OK: Chain has three level architecture - Root which Signs OCSP Policy, Policy which signs issuing CA which signs subscriber CA. $ openssl verify ksmelkovs.pem # Cert to verify ksmelkovs.pem: OK $ openssl verify tssp.pem # OCSP responder cert tssp.pem: OK $ openssl verify cacers/*vas*rca*pem cacers/vas latvijas pasts ssi(rca).pem: OK $ x509 ksmelkovs.pem -text |grep ocsp OCSP - URI:http://ocsp.e-me.lv/responder.eme $ x509 ksmelkovs.pem -text |grep Issue Issuer: C=LV, O=VAS Latvijas Pasts - Vien.reg.Nr.40003052790, OU=Sertifikacijas pakalpojumi, CN=VAS Latvijas Pasts SI(CA2) $ ocsp -issuer cacers/*ca2*pem -cert ksmelkovs.pem -url http://ocsp.e-me.lv/responder.eme *Response Verify Failure 5083:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:148: *ksmelkovs.pem: good This Update: Mar 23 11:29:33 2010 GMT konr...@konrads-laptop:~/Sertifikati$ openssl verify ksmelkovs.pem ksmelkovs.pem: OK Copies of these certs are uploaded here: http://drop.io/lykqq21# The 64k USD question: If I have entire trust chain in trusted list, then why would it complain? There are two automatic trust models for OCSP responder certificates. One is the CA key that signed the certificate also signs responses: that isn't recommended for security reasons. The other is that the CA signs a responder certificate with an OCSP signing EKU extension and responses are signed by the corresponsing private key. Your setup doesn't seem to cover either case. You can explicitly trust the responder certificate with the -VAfile option or add explicit OCSP signing trust to the root. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org tssp-lp.pem Description: Binary data
Re: 4485:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:148:
Understood, this indeed is the case. Is it a violation of good practice, RFC? What are the security risks? -- Konrads Smelkovs Applied IT sorcery. On Tue, Mar 23, 2010 at 7:44 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Tue, Mar 23, 2010, Konrads Smelkovs wrote: Hi, The OCSP responder has EKU=OCSP: X509v3 extensions: X509v3 Subject Key Identifier: 2B:6E:08:08:9D:92:5A:59:CB:BB:46:89:77:E8:A0:17:47:82:88:5C X509v3 Extended Key Usage: OCSP X509v3 Key Usage: Digital Signature, Non Repudiation X509v3 Authority Key Identifier: keyid:CC:C3:F5:66:FF:73:AC:38:5A:96:1B:21:89:B8:81:4C:1F:CB:5E:25 I attached OCSP cert. I believe this is setup #2 you described. It also has to be signed by the same CAs as the certificates it covers, a CA certificate higher up the chain is not permitted in that case. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: 4485:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:148:
What are the risk moments here? Why this clause was put in? -- Konrads Smelkovs Applied IT sorcery. On Tue, Mar 23, 2010 at 8:21 PM, Patrick Patterson ppatter...@carillonis.com wrote: Hi Konrads: No, in order for trust model 2 to work, the OCSP responder would have to be signed by the intermediate CA, not the root CA. The Root CA is authoritative to delegate OCSP responses over the entire subCA tree (which is the model you are using), is unsupported under RFC2560. Change your OCSP responder to use a certificate signed by the SubCA, and everything will work. Best Regards, Patrick. On March 23, 2010 01:07:52 pm Konrads Smelkovs wrote: Hi, The OCSP responder has EKU=OCSP: X509v3 extensions: X509v3 Subject Key Identifier: 2B:6E:08:08:9D:92:5A:59:CB:BB:46:89:77:E8:A0:17:47:82:88:5C X509v3 Extended Key Usage: OCSP X509v3 Key Usage: Digital Signature, Non Repudiation X509v3 Authority Key Identifier: keyid:CC:C3:F5:66:FF:73:AC:38:5A:96:1B:21:89:B8:81:4C:1F:CB:5E:25 I attached OCSP cert. I believe this is setup #2 you described. -- Konrads Smelkovs Applied IT sorcery. On Tue, Mar 23, 2010 at 5:39 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Tue, Mar 23, 2010, Konrads Smelkovs wrote: Hello, I am running OpenSSL 0.9.8g 19 Oct 2007. I have a certificate for which I want to check OCSP response. Root chain is added to root list. OpenSSL says all of it is OK: Chain has three level architecture - Root which Signs OCSP Policy, Policy which signs issuing CA which signs subscriber CA. $ openssl verify ksmelkovs.pem # Cert to verify ksmelkovs.pem: OK $ openssl verify tssp.pem # OCSP responder cert tssp.pem: OK $ openssl verify cacers/*vas*rca*pem cacers/vas latvijas pasts ssi(rca).pem: OK $ x509 ksmelkovs.pem -text |grep ocsp OCSP - URI:http://ocsp.e-me.lv/responder.eme $ x509 ksmelkovs.pem -text |grep Issue Issuer: C=LV, O=VAS Latvijas Pasts - Vien.reg.Nr.40003052790, OU=Sertifikacijas pakalpojumi, CN=VAS Latvijas Pasts SI(CA2) $ ocsp -issuer cacers/*ca2*pem -cert ksmelkovs.pem -url http://ocsp.e-me.lv/responder.eme *Response Verify Failure 5083:error:27069070:OCSP routines:OCSP_basic_verify:root ca not trusted:ocsp_vfy.c:148: *ksmelkovs.pem: good This Update: Mar 23 11:29:33 2010 GMT konr...@konrads-laptop:~/Sertifikati$ openssl verify ksmelkovs.pem ksmelkovs.pem: OK Copies of these certs are uploaded here: http://drop.io/lykqq21# The 64k USD question: If I have entire trust chain in trusted list, then why would it complain? There are two automatic trust models for OCSP responder certificates. One is the CA key that signed the certificate also signs responses: that isn't recommended for security reasons. The other is that the CA signs a responder certificate with an OCSP signing EKU extension and responses are signed by the corresponsing private key. Your setup doesn't seem to cover either case. You can explicitly trust the responder certificate with the -VAfile option or add explicit OCSP signing trust to the root. 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 User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- Patrick Patterson President and Chief PKI Architect, Carillon Information Security Inc. http://www.carillon.ca __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
