3

I'm trying to establish mutual authentication between my Tomcat server and my customer's firewall.

The server certificate we have is from Digicert (Root CA) and RapidSSL (intermediate).

The certificate chain in the ServerHello block is from QuoVadis.

But before the ServerHelloDone line, the Cert Authorities are empty:

*** CertificateRequest
Cert Types: RSA, DSS, ECDSA
Supported Signature Algorithms: SHA256withRSA, SHA256withDSA, SHA256withECDSA, SHA384withRSA, Unknown (hash:0x5, signature:0x2), SHA384withECDSA, SHA512withRSA, Unknown (hash:0x6, signature:0x2), SHA512withECDSA, SHA1withRSA, SHA1withDSA, SHA1withECDSA
Cert Authorities:
<Empty>
ajp-line-1, READ: TLSv1.2 Handshake, length = 4
*** ServerHelloDone
Warning: no suitable certificate found - continuing without client authentication
*** Certificate chain
<Empty>

I'm going by the documentation here - https://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/ReadDebug.html

Should RapidSSL / Digicert be available in the Cert Authorities block for the client auth to continue?

Hrishikesh Choudhari
  • 133
  • 5
  • Note rfc5246 7.4.4 allows certificate_authorities to be empty and "then the client MAY send any certificate []" (for which it has the key) and it's up to the server to decide whether to accept it. Java/JSSE does send the first one in the applicable keymanager -- so you apparently did not provide any key&cert entries in the keystore used _for this (outgoing) connection_ -- which is usually different from the keystore used by Tomcat for incoming connections that in your case presumably includes your Digicert/RapidSSL chain (and key). – dave_thompson_085 Dec 04 '18 at 11:18

1 Answers1

3

Client and server authentication don't have to use the same CAs, but you should tell the server which CAs it should trust to authenticate clients, which seems to be the issue here.

Why? Many people make their own CA and issue certificates directly to their own clients. This saves customers the trouble of going through a sometimes-messy certification on their end. This information is also passed to clients during the TLS handshake.

Another option is to tell clients to get certificates from public CAs: it seems your company did this, and did not specifically tell clients which CA to buy from. If I interpret your description correctly, this client picked QuoVadis to get certified on their end. If you trust QuoVadis to authenticate servers "well enough" for your purposes, then configure the server to trust QuoVadis for client authentication. For Apache:

SSLCACertificateFile /etc/ssl/certs/name-of-quovadis-certificate.crt

Possibly, concatenate all CAs you know and trust (RapidSSL and Digicert, I gather). You can also take a shortcut, and just trust all known CAs. In Debian/Ubuntu:

SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt

Careful though: many CAs will just automatically validate ownership of the domain (Let's Encrypt does this for free, for instance). To cut things short, let's say this: if free domain auto-validation is not good enough for you, look into Cloudflare or just forget commercial CAs and manually issue certificates to your own clients.

If you're the client instead, flip the question around: ask the other side which CAs they trust, possibly add RapidSSL or DigiCert to their list, and make sure the list is sent.

Community
  • 1
Jacopo
  • 246
  • 1
  • 3
  • 1
    I don't think this answer is consistent. The question is whether you must share a single CA (inversely, whether you can have two CA's). You answer Yes (must share a single CA), but then explain how you can have two CA's. – MSalters Dec 03 '18 at 12:11
  • Hmm, guess I was more answering: "Should RapidSSL / Digicert [or QuoVadis] be available in the Cert Authorities block for the client auth to continue?" which seems to be the main concern of the asker. I'm not sure if I can edit to clarify. – Jacopo Dec 03 '18 at 17:08