10

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)
---
Improve this question
1
  • 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, 2018 at 20:17

4 Answers 4

Reset to default
15

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
4
  • 1
    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, 2014 at 10:39
  • 1
    "..Is it because it appeared after SSL3_READ_BYTES..." - Yes, this is correct.
    – Steffen Ullrich
    Oct 28, 2014 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, 2019 at 6:16
  • 1
    @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, 2019 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
1
  • In my case it needed to be the exact opposite: ssl_verify_client_cert = no
    – KittMedia
    Mar 19, 2020 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
4
  • 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, 2015 at 15:54
  • 1
    I know its depreciated. Oh look, a cloud....┏(;-_-)┛
    – AXE Labs
    Oct 28, 2015 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, 2018 at 20:15
  • Go back to pure unencrypted connections, I wanted to write obviously.
    – Patrick Mevzek
    Feb 21, 2019 at 0:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .