What certificate is required for a HTTPS web client call?

[VolkerBarth]

I'm stumbling over the following sentence from the v17 docs on the CREATE PROCEDURE statement (web client):

To make a secure (HTTPS) request, a client must have access to the certificate used to sign the HTTP server's certificate (or any certificate higher in the signing chain).

What does the " (or any certificate higher in the signing chain)" part mean?

Say, I have the following self-signed certificate chain:

1. Web server certificate, issued by 2.
2. CA certificate, issued by 3,
3. Root CA certificate, issued by itself.

The certificates of the CA and the Root CA contain the "Certificate Signing" attribute.

In my tests with a simple web client procedure, I seem to need to specify the 3. certificate (Root CA) to get a successful HTTPS connection, i.e. something like

create or replace procedure WSP_TestResource(in strURL varchar(2000)) 
result( Attribut long varchar,Wert long varchar ) 
url '!strURL'
type 'HTTP:GET'
certificate 'file=C:\\\\MyCertStore\\\\MyRootCA.crt';
call WSP_TestResource('https://MyServer/MyService');

If I use a PEM file with the web server and/or CA certificate without containing the Root CA, the call fails.

(Aside: With v17, "certificate 'file=*'" also works, as the OS cert store contains the Root CA certificate.)

So does that mean the " (or any certificate higher in the signing chain)." phrase actually means "the root CA certificate of the CA that issued the web server certificate"?

Note: The question is focussed on v17 and v12/v16 after the switch to OpenSSL...

(Another aside: The question was also inherently asked in that other FAQ...)

[Vlad]

My comment will be short and simple, without any theory. The purpose of the root CA certificate is to trust all certificates that it signs in the certificate chain.

E.g. you probably know the project Let's Encrypt. They have the certificate chain, where three certificates are used. The root certificate is: CN = IdenTrust Commercial Root CA 1, O = IdenTrust, C = US. It is valid until 2034 probably... I do not know if I see this date, but nevertheless. My Firefox has this certificate in the list of trusted certificates, meaning that I actually trust every certificate that it signs.

If you use the certificate issued by 2 only (without the whole chain), you should somehow trust this certificate too. If the root CA is not an option for you, you have to add the web server certificate to your "trust store" explicitly. This is a bad practice, because there is a chance that if the web server revokes the certificate, you still trust the old one.

On my PCs, I have one-two root CAs that my browsers always trust and thus every new certificate that I issue and sign are trusted by default. The single thing that should be taken into account is the certificate validity. You shouldn't create long-living web server certificates.

If you ignored my comment, because it is long, simple and boring, probably this is the answer you were looking for 🙂

http://stackoverflow.com/questions/34945244/should-the-trusted-root-ca-be-a-part-of-the-certificate-...

If I am wrong, I am sorry 😞

[VolkerBarth]

Thanks for your comment and the SO link!

I guess my question is based on the fact that SQL Anywhere web client calls do not make use of the OS/browser cert store (unless used with v17 and the "file=*" option), so the "trust anchor" must be supplied by the web client explicitly (otherwise one would not have to specify a certificate at all, methinks).

But then again, I would think if the web client supplies the certificate of an intermediate CA (in my sample no. 2) and by this explicitly "trusts" that CA, and the web server's certificate is signed by exactly that intermediate CA, that should suffice for a successful TLS connection.

But apparently, it does not.

Possibly that statement from Graeme's documentation of the OpenSSL changes is key to the understanding:

Trusted certificates
With Certicom, a client could trust any certificate in the signing chain and the TLS handshake would succeed. With OpenSSL, the client must trust the root certificate in the chain.

[Vlad]

Probably the statement you found is the answer, but I do not know. Let's wait what other members say. I assume that SA uses libopenssl, and thus it should inherit its behavior for HTTPS.

[VolkerBarth]

Is there an official answer by the SQL Anywhere engineers available (say, by Graeme)?

[graeme_perrow · Accepted solution]

The docs are incorrect. They were probably written when we used the Certicom cryptographic library, where this was true - you could specify certificate #2 or #3 in the list above as the trusted certificate. With OpenSSL, you need to trust the root certificate (#3).

I listed it as "higher" in the chain just because I would have listed the certificates in the opposite order - root, then CA cert, then web server cert. I'd probably order them that way because that's the order they'd have to be created in. But they appear in the file in the order Volker listed above.