8

I am troubleshooting errors establishing a secure connection to an EPP server. I issue the command below and see that all of the server certificates are verified, but still I get an error (highlighted in bold). Is there still a problem validating the server's certificates? If so, what could it be?

Edit: I snipped the "Acceptable client certificate CA names" because the spam detector didn't like them.

$ openssl s_client -connect otessl.verisign-grs.com:700 -key /home/ubuntu/foo.key -cert /home/ubuntu/foo.crt -CAfile /home/ubuntu/foo-cert-chain.pem  -CApath /etc/ssl/certs

CONNECTED(00000003)
depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority
verify return:1
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5
verify return:1
depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = Terms of use at https://www.verisign.com/rpa (c)06, CN = VeriSign Class 3 Extended Validation SSL CA
verify return:1
depth=0 1.3.6.1.4.1.311.60.2.1.3 = US, 1.3.6.1.4.1.311.60.2.1.2 = Delaware, businessCategory = Private Organization, serialNumber = 2497886, C = US, postalCode = 20190, ST = Virginia, L = Reston, street = 12061 Bluemont Way, O = "Verisign, Inc", OU = Production Operations, CN = otessl.verisign-grs.com
verify return:1
<b>
140403406833312:error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:s3_pkt.c:1260:SSL alert number 46
140403406833312:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
</b>
---
Certificate chain
 0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private Organization/serialNumber=2497886/C=US/postalCode=20190/ST=Virginia/L=Reston/street=12061 Bluemont Way/O=Verisign, Inc/OU=Production Operations/CN=otessl.verisign-grs.com
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL CA
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL CA
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
   i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
*snipped*
-----END CERTIFICATE-----
subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/businessCategory=Private Organization/serialNumber=2497886/C=US/postalCode=20190/ST=Virginia/L=Reston/street=12061 Bluemont Way/O=Verisign, Inc/OU=Production Operations/CN=otessl.verisign-grs.com
issuer=/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL CA
---
Acceptable client certificate CA names
*snipped - will post if needed*
---
SSL handshake has read 10228 bytes and written 4199 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
    Session-ID: 544D9C743C278DCE0AA4715E68CA7C7A3443F3596495EA3A27448B9F3E0AC575
    Session-ID-ctx: 
    Master-Key: 77E6E234FE7313C50C04B7C8F32B0D6C9B6520A114DA4253A97FF1C200544EBB21DBC2C7ECA45DF0546A27EFB466EF4F
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1414372468
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
  • There are a lot of variations in the EPP world: some registries generate certificates for you (and hence you can only connect with it), other registries accept any certificate from some list of CAs (the list is arbitrary per registry, so for example a Let's Encrypt one may work or not), some other registries, in addition, whitelist explicitely your client certificate (so you need to contact them each time you change it). – Patrick Mevzek Sep 4 '18 at 20:17
9

You get the error about certificate unknown from the server, so it refers to the validation of your client certificate on the server side and not to the (successful) validation of the servers certificate at the client side. That means the server does not like your client certificate.

Please check your client certificate against the list of acceptable CAs, make sure it is not revoked and maybe do a tcpdump/wireshark to verify, that it gets actually sent to the server. If this does not help you might check log files at the server side for signs what went wrong.

| improve this answer | |
  • Thank you. Yes, the issue turned out to be that the client certificate was not signed by one of the approved CAs. The Acceptable client certificate CA names list would have told me that I think. But in this case, documentation for the server-side endpoint indicated that only a certain set of client certs would work. Got one of those and it worked. For future reference, how can you be sure that the "certificate unknwon" error was coming from the server? Is it because it appeared after SSL3_READ_BYTES, meaning reading response from server? – shampoopy Oct 28 '14 at 10:39
  • "..Is it because it appeared after SSL3_READ_BYTES..." - Yes, this is correct. – Steffen Ullrich Oct 28 '14 at 11:22
  • @SteffenUllrich, While using a wildcard certificate for example *.abcnet.abc.com I'm getting "SSL Library Error: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown". But for domain like "xyz.abcnet.abc.com" there is no such error. Any ideas on this. Thanks. – Rohit Gaikwad Apr 30 '19 at 6:16
  • @RohitGaikwad: Please don't ask a new question in a comment to an answer. Nobody will expect new questions and answers there so that any helpful information will be lost for others. Please ask a new question instead which also includes all details which are necessary to understand and reproduce your problem. – Steffen Ullrich Apr 30 '19 at 9:04
2

In my case

error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown:s3_pkt.c:1260:SSL alert number 46

was solved by adding

ssl_verify_client_cert = yes

in /etc/dovecot/dovecot.conf.

| improve this answer | |
  • In my case it needed to be the exact opposite: ssl_verify_client_cert = no – KittMedia Mar 19 at 6:29
1

I just experienced something similar.

You may have forgotten to install the CA Certificates.

If you're on ubuntu or debian: apt-get install ca-certificates

| improve this answer | |
0

In my case, the clients did not appreciate being forced to do TLS, but were warm and fuzzy when we added "SSLProtocol +SSLv3" in the https server :|

| improve this answer | |
  • 1
    SSLv3 is deprecated (tools.ietf.org/html/rfc7568) because it's fundamentally insecure (blog.mozilla.org/security/2014/10/14/… ) Are you clients aware their data is not secure? – Andrew Henle Oct 28 '15 at 15:54
  • 1
    I know its depreciated. Oh look, a cloud....┏(;-_-)┛ – AXE Labs Oct 28 '15 at 16:04
  • 1
    At that stage you should just shut the whole TLS stack and go back to pure encrypted connections. Illusion of security is far worse than no security at all. – Patrick Mevzek Sep 4 '18 at 20:15
  • Go back to pure unencrypted connections, I wanted to write obviously. – Patrick Mevzek Feb 21 '19 at 0:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.