I have a Wireshark trace of a client machine I have that when it tries to connect to the server, gets "Bad Certificate". If I use any browser, it works fine and never gets the error. I'm by no means an expert on certificates. Can anyone take a look and see why the certificate is being rejected? The location of the trace is: http://cloudshark.org/captures/9af27d06ecb3?filter=tcp.port%20%3D%3D%20443 asked 27 Jun '12, 15:56  tcoder |
4 Answers:
(OK, a new answer instead of a new comment to threads that are large as they are. I believe this to be the final solution for you) I double checked your tracefiles and you kind of put us on the wrong foot with the following statement: If I open your initial capture file, the “Geotrust Global CA” certificate is in fact not a root certificate but it is signed by yet another CA, namely “Equifax Secure Certificate Authority”. This can also be seen in the IBM trace that you uploaded. So to solve your issue, you should add the “GeoTrust Global CA” Certificate to your certificate chain configured in Apache. In short in your apache confige file:
To make things easy for you (and since it is easier to do myself than to explain on how to do it), I created the concatenated file for you, so you can just copy & paste the following to a file: answered 03 Jul ‘12, 08:57  SYN-bit ♦♦ edited 03 Jul ‘12, 08:58 |
From RFC 2246 The client notifies the server, that the certificate was 'corrupt'. In that case you should see an error in the browser! HINT: Why do you get a certificate from one of your internal systems (192.168.5.104) with a subject of cn=cden.chetest.com? That domain is parked by godaddy.com, so there should be no such certificate on your network, except you generated it! Did you? As I mentioned in my other answer, there are signs that 'something' is possibly tampering with your network traffic on the lan (including the SSL connection). However, without further information, this is just speculation, based on the data in the capture file. Regards answered 27 Jun '12, 17:16  Kurt Knochner ♦ edited 27 Jun '12, 17:38 We've got a special case such that we needed a signed certificate by a CA. The URL of cden.chetest.com is in the host file of the PC the Apache webserver is in. The cden.chetest.com is actually 192.168.5.104. We had GeoTrust create the certificate from our CSR file. Anyway, when I take any browser and execute it on the server machine with https://cden.chetest.com, it brings up the webpage with no errors whatsoever. The certificate was originally purchased by GoDaddy and we own the domain name. I ran out of characters. I'll finish up in the next comment. Regards, Terry (27 Jun '12, 20:18) tcoder You mentioned the two MAC addresses. One is the MAC of the router and the other is the MAC of the Ethernet card in the server. They are the two MACs between the router and the server. The cn of the certificate is cden.chetest.com. If it was possible, I would use the private IP address for the CN. I made a self-signed certificate with that but our client machine gets an unknown CA error. If you need anymore info, let me know. Regards, Terry (27 Jun '12, 20:19) tcoder :-) It would have been easier, if you had given that information in the first place. Without that information, it really looks a bit strange ;-) O.K. So, it's your cert. What do you see if you load the page with curl?
Put the public Key of the GoDaddy root CA into the file ca-bundle.pem. There is an explanation how to create the ca bundle file. An automatically generated ca bundle file (based on Firefox trusted root ca list), can be downloaded here:
The root ca of GoDaddy should be in that file, but I did not check! curl will create a trace file with SSL protocol messages. Maybe that gives some further hints. Sniff the curl traffic with Wireshark and compare the results. If there is an Alert in Wireshark, but none in curl (as you mentioned the browsers), post the output of the trace file and the capture file. If there is no Alert message with curl, you need to have a closer look at your browser. (28 Jun '12, 00:35) Kurt Knochner ♦ comment moved to this question, as it confuses the 'flow' here ;-) (28 Jun '12, 01:17) Kurt Knochner ♦ I don't understand this sentence: What do you see if you load the page with curl? I tried the curl command and here is what I got. I ran it from the server PC. C:\Program Files\Curl>curl --trace trace.txt --cacert ca-bundle.pem https://cden.chetest.com curl: (77) error setting certificate verify locations: CAfile: ca-bundle.pem CApath: none (28 Jun '12, 16:34) tcoder The error means, that the specified file 'ca-bundle.pem' does not exist. Download this File http://curl.haxx.se/ca/cacert.pem and save it to C:\Program Files\Curl\ca-bundle.pem. Then run the command again and post the trace file in an answer, together with a capture file on cloudshark.org. (28 Jun '12, 23:00) Kurt Knochner ♦ I couldn't post the entire message as I ran out of characters. I did what you said and it got another error: curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. (29 Jun '12, 08:21) tcoder I stopped the server and got an error saying the host was unavailable. Then I restarted it. Therefore I know that it is getting to the server. (29 Jun '12, 08:48) tcoder showing 5 of 8 show 3 more comments |
The configured intermediate certificate is not correct. Your server certificate is signed by: While the Intermediate CA that you have configured in your webserver is: You need to configure the intermediate for "GeoTrust DV SSL CA" (and maybe more intermediate CA's) for this to work. answered 29 Jun '12, 07:37 SYN-bit ♦♦
should'nt the brower bring up an error message if the intermediate CA is wrong? (29 Jun '12, 07:49) Kurt Knochner ♦ How do I get the formatting correct? It's all run together. I went back to where they sent me the certificates. What they sent me was: Issued To: cden.chetest.com Issued By: GeoTrust DV SSL CA Issued To: GeoTrust DV SSL CA Issued By: GeoTrust Global CA Issued To: GeoTrust Global CA Issued By: GeoTrust Global CA I don't know what to do now. What do I use as the Server Certificate if I make GeoTrust DV SSL CA an intermediate certificate? (29 Jun '12, 08:09) tcoder They sent me a .p7s file with the 3 certificates above. I'm thnking that I extracted the certificates wrong. How should I have done it? (29 Jun '12, 09:16) tcoder
The only one for which you have the private key, cden.chetest.com! Let's go back to the browsers. Do you really get NO error message at all? Look at the certificate chain. Connect to the server, then open the cert and look at the tab "certificate chain" (IE). Does the browser show all intermediate CAs? (29 Jun '12, 09:17) Kurt Knochner ♦ Yes, if I use IE or Chrome and enter https://cden.chetest.com/index.html, I don't get any errors on the browser screen as long as the browsers are on the server PC. If I use the same browsers on another PC, I get an error stating that it can't find the webpage. If I use the IP address instead, I get the error stating that the URL isn't the same as the common name. Concerning the certificates, from right bottom to top left I get cden.chetest.com, GeoTrust DV SSL CA, GeoTrust Global CA. The Certificate status, on the bottom of the form says "This certificate is OK". (29 Jun '12, 12:59) tcoder OK, My Firefox already has that Intermediate in it's trusted authority list. But if some browsers/clients only have root CA's, then you need to supply the Intermediate. And at least you need to not supply the wrong one. So, you would use the following: The other certificate is the root CA and you don’t need to configure that, it’s already in all popular browsers. (29 Jun ‘12, 13:50) SYN-bit ♦♦
IE and Chrome use the Cert store of Windows. I assume, you have all required intermediate CAs in the store.
Did you add the hostname to the hosts file? If not, you would connect to the external address of cden.chetes.com (208.87.35.107) and there is no service listening on tcp/443!!
Is that is the only error? No error regarding "issuer cert"?
When do you see this? If you connect from the Server, any PC? Access with hostname or with ip address? BTW: The capture file with the Alert relates to which connection attempt? (30 Jun '12, 00:52) Kurt Knochner ♦ IE and Chrome use the Cert store of Windows. I assume, you have all required intermediate CAs in the store: Did you add the hostname to the hosts file? If not, you would connect to the external address of cden.chetes.com (208.87.35.107) and there is no service listening on tcp/443!! (02 Jul '12, 09:44) tcoder When do you see this? If you connect from the Server, any PC? Access with hostname or with ip address? BTW: The capture file with the Alert relates to which connection attempt? This is the capture file of the HMC (192.168.5.103) to the server (192.168.6.104). (02 Jul '12, 12:09) tcoder showing 5 of 9 show 4 more comments |
Try this:
Check if the output looks O.K. (should be several certs in there). Remove the cert of cden.chetest.com if it was also in the p7s (should be). Then use the server cert and the intermediate CAs, as described here:
If you prefer a GUI wrapper for openssl, I recommend XCA.
Regards answered 29 Jun '12, 09:35 Kurt Knochner ♦ edited 30 Jun '12, 00:38 I tried the openssl command but it failed stating that "in" is an invalid commend. (29 Jun '12, 12:23) tcoder sorry,'pkcs7' was missing. Please try again. (30 Jun '12, 00:38) Kurt Knochner ♦ There are 3 certs in the file: Cert #1 subject=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA Cert #2 subject=/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA Cert #3 subject=/serialNumber=kmWaloVmfmBbYPVRYDjZrMhK6hqymshv/OU=GT07032149/OU=www.geotrust.com/resources/cps/OU=Domain Control Validated - GeoTrust(R) SSL Trial/CN=cden.chetest.com issuer=/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA Which one do I remove and what do I do with the rest? (02 Jul '12, 09:21) tcoder Cert #3 is for your server. Apache config file: SSLCertificateFile. The corresponding private key goes to SSLCertificateKeyFile. Cert #2 is the intermediate CA. Apache config file: SSLCertificateChainFile Cert #1 you don't need that on the server. Import that CA cert into your browser cert store, IF it is not already there (rather unlikely). If you don't get any SSL Alerts after that, please select the answer of SYN-Bit as the correct one, as he first pointed out the problem with the wrong intermediate CA! (02 Jul '12, 10:01) Kurt Knochner ♦ I followed the previous instructions and kept getting an error stating that the keyfile didn't match the server certificate. I found a combination of server cert and intermediate cert that doesn't get "bad Certificate". Now I get "unknown CA". I uploaded the trace to Cloudshark. Here is the trace: http://cloudshark.org/captures/8e9dc27a2306?filter=tcp.port%20%3D%3D%20443 Just to make sure you know, this is the HMC (client) connecting with my Apache server on Windows XP. (02 Jul '12, 17:01) tcoder I made another Wireshark trace on the server PC and got a cleaner result with no retries as before. I uploaded it to Cloudshark and the URL is: http://cloudshark.org/captures/1b67ed75d869?filter=tcp.port%20%3D%3D%20443 This is a trace of the HMC connecting to the Apache server getting an error of "unknown CA". The next trace is where the HMC contacts the IBM website with no failure. http://cloudshark.org/captures/6a47effe6552?filter=ip.addr%20%3D%3D%20192.168.5.103 Can someone look at the two traces and help showing me what cert I should add to the "unknown CA" connection if possible? (03 Jul '12, 07:38) tcoder showing 5 of 6 show 1 more comments |
I hope so as well ;-)
It looks like that fixed it! It got rid of the unknown CA error and went on to access the webpage with errors as I expected it would. I’m appreciative of everyones patience with my ignorance of SSL. Thanks for all of your help.
Terry