Q: Server 3 / SSL Certificate / Open Directory - Problem!

In terminal if you do a  "openssl s_client -connect 127.0.0.1:636"  (sudo or root)

do you also get an error in line 3?

verify error:num=19:self signed certificate in certificate chain

@Gavin its a Apple problem handeling Comodo certificate can you also add a bug at https://bugreport.apple.com ? Maybe this will speed up some investigation there thanks

Hi Peter,

I too get that error but perhaps you could take a few mins to explain why that shows it is a bug with Apple.  A self-signed cert is what my system is configured to use since the COMODO cert wasn't accepted, so I don't understand what the openssl s_client command is testing regarding the COMODO cert?

I'm happy to submit a bug report as well, as I have one with COMODO too.  Everyone is pointing to Apple; I'm pointing at both until I see resolution or I ask for a return from COMODO.  BTW, they tried to tell me they are not authorized by Apple to talk with Apple about the problem?!?  I let that go because it didn't make any sense to me why a company would agree with Apple to not talk with Apple. :-~

In my workings with COMOODO, I noticed that Apple has a COMODO root CA cert in the System Roots, and that COMODO also has users install an intermediate with the same CN.  When I try to evaluate certs at each level, I get results for which I don't personally understand the consequences. More specifics:

I have two COMODO Certification Authority certs.  One is in System Roots, it is listed as a Root certificate authority, and it has an expiration date of 12/31/2029. The second is an intermediate CA in System and it expires 5/30/2020.  They both have the same CN.  Is this right?  I’ve confirmed this on another server.

So, when I evaluate *.mydomain.com, it shows No root found but tries to establish a trust chain back to AddTrust External CA.   

When I evaluate EssentialSSL, it stops with the COMODO root. 

When I evaluate COMODO CA (Intermedate) it says “No root cert found” but tries to establish a trust chain back to AddTrust External CA

When I evaluate COMODO CA (root) in System Roots, it says “Success” and “Root ALSO in System Roots”

When I evaluate UTN - DATACorp SGC in System, it says “No root cert found” but shows a trust chain back to AddTrust External CA Root

When I evaluate AddTrust External CA Root, is says success but still also says “Root ALSO in System Roots”.

I've asked COMODO support about this and they are investigating further. 

Again, I am not knowledgeable enough about this to fully understand, but it causes me to wonder if the evaluation of a cert is generating errors because there are two different certs with the same CN?  Or is this completely normal and unrelated?

Tim

Iam no expert in certficates, but the Comodo certficate works (perfect) with 10.8.5 and after the upgrade (test) to 10.9.1 i get the self sign certicates errors and open directory is not working any more with the certificate. Also when i setup a new (test)server with the certificate same problem. So it looks that the problem begins with 10.9 and higher.

so I don't understand what the openssl s_client command is testing regarding the COMODO cert

nothing just a test and you have the same problem

In my case only OD is refusing to work with the certificate the others web etc. have no problem

I agree with both of you.  I recently saw a thread from a couple years ago that talked about the fact that Apple started enforcing longer keys in SSL certs (if I recall correctly) but they didn't tell everyone.  So, things started breaking.  Not really a bug per se, but rather a unpublished standard.  If something similar has happened here, then COMODO might be able to make the adjustment on their end.  Again, just why I am pushing on both for now.  Clearly something changed in Apple's code.  I'm not completey convinced it is a bug vice an unpublished standard.

Do either of you see the same behavior I described above when evaluated certificates?

Tim

Thanks all, for the info in this thread. I'm seeing the same issue on 10.9.1 and using an InCommon/Comodo cert.

@ Peter-Erik. (I'm not picking just trying to understand this better) If you have your web server running and run "sudo openssl s_client -connect 127.0.0.1:443" you should see the same error as for LDAPS .

verify error:num=19:self signed certificate in certificate chain

I believe that is actually the correct and expected output. See http://stackoverflow.com/questions/4103472/ssl-handshake-fails-with-a-verisign-c hain-certificate-that-contains-two-ca-s

Also from the openssl command I'm seeing "Secure Renegotiation IS supported" and "Verify return code: 0 (ok)" So I think the cert is actually there and working for LDAP?

*** The one issue I see when I run the command is that the session doesn't close properly when run against 636. I have to ^C to get it to drop the connection. For port 443 it closes fine. I'm not sure what's going on there.

Also whenever I try to set the InCommon cert for OD I get the following note in the "Configuration Log" for OD.

2014-02-05 19:08:56 +0000 slapconfig -setldapconfig

2014-02-05 19:08:56 +0000 Provided SSL Identity server.example.com is already configured for OD.

It looks like it's all working but something isn't showing up in the GUI. If we could get someone  not seeing the issue to run "sudo openssl s_client -connect 127.0.0.1:636" then we might see what the differences are. Here is my output with key info redacted.

$ sudo openssl s_client -connect 127.0.0.1:636

Password:

CONNECTED(00000003)

depth=2 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

verify error:num=19:self signed certificate in certificate chain

verify return:0

---

Certificate chain

0 s:/C=US/postalCode=12345/ST=ST/L=City/street=7th St./street= M005/O=My University/OU=DEPT/CN=server.example.com

   i:/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA

1 s:/C=US/postalCode=12345/ST=IST/L=City/street=7th St./street= M005/O=My University/OU=DEPT/CN=server.example.com

   i:/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA

2 s:/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA

   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root

---

Server certificate

-----BEGIN CERTIFICATE-----

xxx

xxx

-----END CERTIFICATE-----

subject=/C=US/postalCode=12345/ST=ST/L=City/street=7th St./street= M005/O=My University/OU=DEPT/CN=server.example.com

issuer=/C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA

---

No client certificate CA names sent

---

SSL handshake has read 5217 bytes and written 456 bytes

---

New, TLSv1/SSLv3, Cipher is AES256-SHA

Server public key is 2048 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

    Protocol  : TLSv1

    Cipher    : AES256-SHA

    Session-ID: xxx

    Session-ID-ctx:

    Master-Key: xxxx

    Key-Arg   : None

    Start Time: 1391629409

    Timeout   : 300 (sec)

    Verify return code: 0 (ok)

---

Interestly, my output for the Certificate chain is different. Mine reflects the self-signed OD Intermediate CA the system set up. And CNs vice OU/C field names. 

That sure doesn't help me understand the expected behavior :-(

Tim

So with further research it does appear, as Peter-Erik stated, verify error:num=19 is not correct behavior. Take a look at the info at http://jw35.blogspot.com/2010/05/doing-certificate-verification-in.html

"If you see "Verify return code: 19 (self signed certificate in certificate chain)" then either the servers is really trying to use a self-signed certificate (which a client is never going to be able to verify),or OpenSSL hasn't got access to the necessary root but the server is trying to provide it itself (which it shouldn't do becasue it's pointless - a client can never trust a server to supply the root coresponding to the server's own certificate)."

I think this has something to do with the issue of not being able t select the cert for OD but I coudl be on a very wrong track. I've removed the AddTrust External TTP Network cert from the System certs. It's still in System Roots, and should be as far as I know. Even so I still see the verify error. Also when I use the web server and test it for SSL using https://www.ssllabs.com/ssltest/index.html. SSL labs is also showing an issue with the root cert in the chain.

Maybe someone with more knowledge about how this works can help.

Just got word that my bug (http://openradar.appspot.com/15914873) has been marked as a duplicate of 15691451 which is still open.

I don't claim to be more knowledgeable, but what you're describing is also why I'm most intrigued by the results when I try to evaluate certificates, and the fact that I have two for COMODO with the same CN.  My hypothesis is that the system cannot find the right root, FWIW.

Tim