When establishing a secure connection to an EPP server using OpenSSL's s_client, you might encounter the following error even when certificate verification appears successful:
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:
The "certificate unknown" alert (number 46) typically indicates that while the server certificate chain verifies correctly, there's an issue with client certificate authentication. The server is rejecting your client certificate, not the server's own certificates.
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...
verify return:1
depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network...
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...
verify return:1
All these verify return:1 indicate successful verification of the server's certificate chain.
- The client certificate isn't signed by a CA that the server trusts
- The client certificate has expired or isn't yet valid
- The certificate's CN or SAN doesn't match what the server expects
- Missing intermediate certificates in the client's certificate chain
- Server-side policy restrictions on acceptable certificates
First, verify your client certificate independently:
openssl verify -CAfile /home/ubuntu/foo-cert-chain.pem /home/ubuntu/foo.crt
Check the certificate details:
openssl x509 -in /home/ubuntu/foo.crt -text -noout
Try providing the full chain of trust for both server and client certificates:
openssl s_client -connect otessl.verisign-grs.com:700 \
-key /home/ubuntu/foo.key \
-cert /home/ubuntu/foo.crt \
-CAfile /home/ubuntu/combined-ca.pem \
-showcerts \
-status \
-debug
Where combined-ca.pem contains both:
- The server's CA chain
- The client certificate's CA chain
For more detailed debugging, add these flags:
-msg -state -tlsextdebug
This will show the complete SSL/TLS handshake process and may reveal why the server is rejecting the client certificate.
The EPP server may have specific requirements for client certificates. Check if:
- The certificate needs specific extended key usage (EKU)
- There are CN/SAN pattern requirements
- Certificate policies or other extensions are required
When working with EPP servers or other secure connections, you might encounter a puzzling scenario where OpenSSL's s_client
shows successful server certificate verification but still throws a "certificate unknown" alert (SSL alert number 46). Here's what's happening under the hood:
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:
- The certificate chain verification succeeds (all
verify return:1
lines) - The final verify return code shows 0 (ok)
- Yet the handshake fails with alert 46
- The cipher negotiated is RC4-MD5 (considered weak by modern standards)
The "certificate unknown" alert typically indicates the server rejected your client certificate. Even though server verification succeeded, the mutual authentication failed because:
- The server requires client certificate authentication
- Your provided client certificate wasn't accepted
- The CA names list (which you snipped) shows which CAs the server trusts
Here's how to properly diagnose and fix this:
# 1. Check if the server requires client auth
openssl s_client -connect otessl.verisign-grs.com:700 -showcerts
# 2. Verify your client certificate against the server's trusted CAs
openssl verify -CAfile /path/to/server/trust/chain.pem your_client.crt
# 3. Check certificate expiration
openssl x509 -in your_client.crt -noout -dates
# 4. Inspect the certificate's purpose
openssl x509 -in your_client.crt -noout -purpose
Try these solutions:
# Solution 1: Ensure proper certificate chain
openssl s_client -connect host:port \
-key client.key \
-cert client.crt \
-CAfile full_chain.pem
# Solution 2: Check for matching certificate types
openssl x509 -in client.crt -noout -text | grep -A1 "X509v3 Extended Key Usage"
# Solution 3: Verify certificate and key match
openssl x509 -noout -modulus -in client.crt | openssl md5
openssl rsa -noout -modulus -in client.key | openssl md5
For persistent issues:
- Capture a full packet trace with Wireshark
- Check server-side logs for rejection reasons
- Test with different cipher suites using
-cipher
parameter - Verify OCSP/CRL status if the server performs revocation checking
Remember that some EPP servers have strict requirements about certificate attributes like extendedKeyUsage or subjectAltNames.