Having a problem with SSL on ruby 1.9.2, Ubuntu 10.10. Think it’s a
cacerts problem, but not sure which file it’s looking at.
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
certificate verify failed
Works in MacOSX 10.6 but fails in both Ubuntu 10.10 and 10.4.
Certificate is a valid godaddy cert. Can turn verification off in ruby
but that’s obviously not very desirable ; )
Any pointers would be greatly appreciated!
Thanks!
Gerald
Gerald A. wrote in post #955125:
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
certificate verify failed
First, take Ruby out of the loop: use
openssl s_client -CApath /etc/ssl/certs -connect x.x.x.x:p
and if you don’t understand what you see, you can post it here.
If s_client verifies OK, but ruby doesn’t, then you’re probably missing
the CApath parameter in your ruby code or have pointed it to the wrong
directory.
Brian, Thanks for response. Sure enough, it’s still not verifying:
depth=0 /O=www.mydomain.com/OU=Domain Control
Validated/CN=www.mydomain.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /O=www.mydomain.com/OU=Domain Control
Validated/CN=www.mydomain.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /O=www.mydomain.com/OU=Domain Control
Validated/CN=www.mydomainj.com
verify error:num=21:unable to verify the first certificate
verify return:1
I guess I’ll start googling on that, if you have suggestions I’m more
than all ears ; )
Thanks!
Gerald
Brian C. wrote in post #955152:
Gerald A. wrote in post #955125:
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
certificate verify failedFirst, take Ruby out of the loop: use
openssl s_client -CApath /etc/ssl/certs -connect x.x.x.x:p
and if you don’t understand what you see, you can post it here.
If s_client verifies OK, but ruby doesn’t, then you’re probably missing
the CApath parameter in your ruby code or have pointed it to the wrong
directory.
Oops, forgot the chain:
Certificate chain
0 s:/O=www.mydomain.com/OU=Domain Control Validated/CN=www.mydomain.com
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
Inc./OU=Sign In Daddy Secure
Certification Authority/serialNumber=07969287
Gerald A. wrote in post #955157:
Brian, Thanks for response. Sure enough, it’s still not verifying:
depth=0 /O=www.mydomain.com/OU=Domain Control
Validated/CN=www.mydomain.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /O=www.mydomain.com/OU=Domain Control
Validated/CN=www.mydomain.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /O=www.mydomain.com/OU=Domain Control
Validated/CN=www.mydomainj.com
verify error:num=21:unable to verify the first certificate
verify return:1I guess I’ll start googling on that, if you have suggestions I’m more
than all ears ; )Thanks!
GeraldBrian C. wrote in post #955152:
Gerald A. wrote in post #955125:
SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
certificate verify failedFirst, take Ruby out of the loop: use
openssl s_client -CApath /etc/ssl/certs -connect x.x.x.x:p
and if you don’t understand what you see, you can post it here.
If s_client verifies OK, but ruby doesn’t, then you’re probably missing
the CApath parameter in your ruby code or have pointed it to the wrong
directory.
Well, if you were to post the actual certificate (PEM file) then I can
look at it. A certificate is public information after all. Obviously not
the private key which goes with it 
Otherwise, I can’t help you, and it’s not a ruby issue anyway. It’s a
problem somewhere between Ubuntu and its certs repository.
Looking on an Ubuntu 10.04 box, I see:
$ find /etc/ssl/certs/ -iname ‘daddy’
/etc/ssl/certs/Go_Daddy_Class_2_CA.pem
/etc/ssl/certs/UbuntuOne-Go_Daddy_CA.pem
/etc/ssl/certs/UbuntuOne-Go_Daddy_Class_2_CA.pem
But without your PEM I can’t check if these are the CA certs you need.
Wasn’t a security issue, just trying to keep the thread clean ; )
Here’s the whole mess:
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID:
3A1A18B19DB8D1BDC808FDE28B9E1E08A9CB6C2439D58719426ABC2D02FED434
Session-ID-ctx:
Master-Key:
1C0F6B40085031345A8BADACE239BD54F38A7ED6DF347A99EBFBC0D0E45414860EBADB75D97E2D954F43A0C8709A668A
Key-Arg : None
TLS session ticket:
0000 - 7a 74 7d 2a 8c 69 07 a2-b5 b5 ac 7b 75 0e a0 fb
zt}*.i…{u…
0010 - 5b 01 b4 c5 c8 f2 d4 79-c1 f7 de 04 69 5f 8f ce
[…y…i_…
0020 - c3 3b c8 47 9b c9 9a 13-ea 29 df b5 52 2b ec 6f
.;.G…)…R+.o
0030 - 5b 4f 92 39 d8 ab 8d 52-b1 49 cd ea ed ca 86 3e
[O.9…R.I…>
0040 - f9 f3 2b 39 ae 38 9e ac-d7 f3 9b 2b fc 58 37 be
…+9.8…+.X7.
0050 - 68 ff 2c f0 b8 5a ed e3-a5 ba ea a0 31 dd 86 a8
h.,…Z…1…
0060 - a8 6f d9 bf a8 0c c9 ef-be be 07 eb e7 37 ae 49
.o…7.I
0070 - 6e 17 79 2c 17 12 9a ca-dc 8a 94 8d 61 54 e3 3b
n.y,…aT.;
0080 - 52 37 75 2f 49 4e 56 24-25 d8 49 6e 63 fc 3f 89
R7u/INV$%.Inc.?.
0090 - ca af da fc 83 77 c9 5c-4f 2b a3 24 ce a8 da 33
…w.\O+.$…3
00a0 - eb 1e a8 5d 9b 50 a3 80-90 a5 5b 37 0c 20 f4 ac
…].P…[7. …
00b0 - e1 9d ca 6d d6 2c 0d 51-4a d7 b6 b6 0b 9e 18 e2
…m.,.QJ…
Compression: 1 (zlib compression)
Start Time: 1287416918
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
Available pems:
lrwxrwxrwx 1 root root 58 2010-10-09 10:23 Go_Daddy_Class_2_CA.pem →
/usr/share/ca-certificates/mozilla/Go_Daddy_Class_2_CA.crt
-rw-r–r-- 1 root root 1778 2010-04-15 09:28 UbuntuOne-Go_Daddy_CA.pem
-rw-r–r-- 1 root root 1449 2010-04-15 09:28
UbuntuOne-Go_Daddy_Class_2_CA.pem
Obviously just the one.
Thanks
Brian C. wrote in post #955196:
Well, if you were to post the actual certificate (PEM file) then I can
look at it. A certificate is public information after all. Obviously not
the private key which goes with itOtherwise, I can’t help you, and it’s not a ruby issue anyway. It’s a
problem somewhere between Ubuntu and its certs repository.Looking on an Ubuntu 10.04 box, I see:
$ find /etc/ssl/certs/ -iname ‘daddy’
/etc/ssl/certs/Go_Daddy_Class_2_CA.pem
/etc/ssl/certs/UbuntuOne-Go_Daddy_CA.pem
/etc/ssl/certs/UbuntuOne-Go_Daddy_Class_2_CA.pemBut without your PEM I can’t check if these are the CA certs you need.
No need to hide your domain name, it’s in the pem file 
And I see
that
$ openssl verify -CApath /etc/ssl/certs ert.pem
gives a failure too.
But I think I know the reason now. There are two GoDaddy certificates, a
root CA (“Go Daddy Class 2 Certification Authority”) and an intermediate
one (“Go Daddy Secure Certification Authority”), which is signed by the
root one.
$ openssl x509 -in /etc/ssl/certs/UbuntuOne-Go_Daddy_CA.pem -noout
-subject -issuer
subject= /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com,
Inc./OU=Sign In Daddy Secure
Certification Authority/serialNumber=07969287
issuer= /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
Certification Authority
$ openssl x509 -in /etc/ssl/certs/UbuntuOne-Go_Daddy_Class_2_CA.pem
-noout -subject -issuer
subject= /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
Certification Authority
issuer= /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2
Certification Authority
$ openssl verify /etc/ssl/certs/UbuntuOne-Go_Daddy_CA.pem
/etc/ssl/certs/UbuntuOne-Go_Daddy_CA.pem: OK
And your certificate is signed by the intermediate one:
$ openssl verify -CAfile /etc/ssl/certs/UbuntuOne-Go_Daddy_CA.pem
ert.pem
ert.pem: OK
Now, you can see that the /etc/ssl/certs directly doesn’t have a hashed
entry pointing to the intermediate CA cert:
$ ls -l /etc/ssl/certs | grep -i daddy
lrwxrwxrwx 1 root root 23 2009-12-19 19:55 219d9499.0 →
Go_Daddy_Class_2_CA.pem
lrwxrwxrwx 1 root root 58 2009-12-19 19:55 Go_Daddy_Class_2_CA.pem
→ /usr/share/ca-certificates/mozilla/Go_Daddy_Class_2_CA.crt
-rw-r–r-- 1 root root 1778 2009-10-12 15:24 UbuntuOne-Go_Daddy_CA.pem
-rw-r–r-- 1 root root 1449 2009-10-12 15:24
UbuntuOne-Go_Daddy_Class_2_CA.pem
but actually that’s correct. It’s the web server’s responsibility to
send both its own certificate and the intermediate certificate back to
the client. The client needs to locate only the root certificate locally
to validate the whole chain.
You need to configure your webserver to send both your server’s
certificate and the intermediate CA certificate. For Apache, there is
some brief information here:
http://www.modssl.org/docs/2.8/ssl_faq.html#ToC39
If that’s not sufficient, and it is Apache you’re using, I can dig out
some working configs.
If it worked on the Mac, it’s because the Mac has wrongly included the
GoDaddy intermediate certificate in its set of trusted root
certificates.
Regards,
Brian.
Brian,
Thanks, that got me where I needed to be. Seems you could make a
serious study out of just SSL alone sigh.
Also, just for future reference if other folks go the same way - as far
as “hiding” domains and such, I am suitably impressed but you’re making
assumptions as to my motivations (again ; ) that are false and don’t
seem to me to add anything to the discussion. That said, I do very much
appreciate your assistance, doubly so in the context of it not actually
being a Ruby issue.
Thanks again!
Gerald
Gerald A. wrote in post #955417:
as far as “hiding” domains and such
…
you’re making
assumptions as to my motivations (again ; ) that are false and don’t
seem to me to add anything to the discussion.
Your motivation doesn’t concern me. It’s just that if I can’t see the
actual output that’s on your screen, but a version which has been
munged in unspecified ways, then it’s much harder to work out what’s
going on - it becomes a guessing game.
I’m glad the problem is solved though.
Regards,
Brian.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs