on 2019 Nov 05 12:02 PM
I'm using 16.0.0.2798 with web service functions (with OTRS FWIW). This works well with HTTP. Now, when switching to HTTPS, I get the following error:
The secure connection to the remote host failed: TLS-Handshake failed, Error code 18 – SQLCODE=-990, ODBC 3 State="HY000"
However, the same function with the same certificate does work with 17.0.10.5923. Are there known differences w.r.t. to TLS between these versions?
The supplied certificate includes a self-signed root CA, it includes the whole chain from web server certificate to CA to root certificate, and the CA and root certificates both contain the "Certificate Signing" attribute. According to the following FAQ, that should be sufficient IMHO. (It does also work with v17 when the web server certificate is omitted.)
Is there something more I can test with v16? (The new certificate v17 options like "skip_certificate_name_check" are apparently not allowed with v16.)
(Unfortunately I cannot upgrade to v17 currently.)
Error code 18 indicates that the server's certificate is self-signed but doesn't appear in the list of trusted certificates. I'm not sure that's actually what's happening but you did say that if you only specified the trusted root, then things work. That's the typical use case - server supplies the entire chain including the server's certificate and private key, and the client supplies only the root certificate. I don't know why OpenSSL is not accepting the connection but you have the solution - only specify the trusted root.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
you did say that if you only specified the trusted root, then things work
No, that's a misunderstanding. With v16 and v17.0.8.4003, it does not work no matter whether I include the web server's certificate (WS) or not. In all test cases I included the certificate of the intermediate CA (ICA) and the root CA (RCA), and the latter is self-signed.
In other words:
Here's the (modified) viewcert output for the supplied certifite file (for the first entry), and the first certificate's common name is exactly the one used in the web client's URL clause:
SQL Anywhere X.509 Certificate Viewer Version 17.0.10.5923 X.509 Certificate ----------------- Common Name: www.[...] Country Code: ... State/Province: ... Locality: ... Organization: ... Organizational Unit: ... Issuer: MY-CA Serial Number: ... Issued: Nov 30, 2015 16:27:37 Expires: Nov 28, 2020 16:27:37 Signature Algorithm: RSA, SHA256 Key Type: RSA Key Size: 4096 bits Key Usage: Digital Signature, Key Encipherment X.509 Certificate ----------------- Common Name: MY-CA Issuer: MY-ROOT-CA Serial Number: ... Issued: Jul 4, 2015 11:42:53 Expires: Jul 4, 2030 11:52:53 Signature Algorithm: RSA, SHA256 Key Type: RSA Key Size: 4096 bits Basic Constraints: Is a certificate authority, path length limit: 0 Key Usage: Digital Signature, Certificate Signing, CRL Signing X.509 Certificate ----------------- Common Name: MY-ROOT-CA Issuer: MY-ROOT-CA Serial Number: ... Issued: Jul 4, 2015 10:59:00 Expires: Jul 4, 2045 11:08:59 Signature Algorithm: RSA, SHA256 Key Type: RSA Key Size: 4096 bits Basic Constraints: Is a certificate authority, path length limit: 0 Key Usage: Digital Signature, Certificate Signing, CRL Signing
If I specify only the root certificate, the call fails in both versions:
I add more combinations in my first comment.
FWIW, for all test cases, I used CREATE CERTIFICATE FROM FILE and supplied the cert via a clause like
certificate 'cert_name=CERT_MY_ROOT_CA'
For v17.0.10.5923, it also works with the 'FILE=*' clause because the ICA and RCA are stored in the machine's certificate store. Of course, v16 does not accept that and raises "The specified certificate is not valid - SQLCODE=-1588, ODBC 3 State="HY000""
And one more test result:
I tried to be clever and thought of turning my web client functions into proxy functions (i.e. CREATE FUNCTION ... AT) that would call a SA17.0.10 "proxy database" that would just do the real web client function calls (because they do work). But of course, I missed that subtle detail:
A proxy function can return any data type except DECIMAL, NUMERIC, LONG VARCHAR, LONG NVARCHAR, LONG BINARY, XML, or any spatial data type.
As the web client function must handle XML datatypes, that is currently a no-go. Sigh.
Ah, I should have thought about @Graeme's and @Tim's answers more thorough... Further tests via OpenSSL's s_client have revealed that this is not related to ciphersuites (as I had thought up-to-now) but to SNI:
When checking the connection with browsers, I always do get the expected certificate, so I was sure the certificate is configured correctly. (Of course modern browsers do support SNI.)
However, when testing with s_client against the same URL and varying server names, the web server in question does return different certificates, and one of them is a self-signed one (i.e. not signed by our usual root CA), and that is the one returned by default, i.e. without using SNI. (Apparently, that is a webserver misconfiguration.)
Now, when I use that particular certificate within the web client call, all is well...
Error code 18 indicates that the server's certificate is self-signed but doesn't appear in the list of trusted certificates.
So in the end, that error is truly correct, as I had supplied the root certificate of a different certificate chain.
In my understanding, 17.0.10 does cope with that as it uses SNI and therefore the web server returns the expeceted certificate.
@Graeme, could this be a restriction due to RSA ciphers?
I checked with another HTTPS web server certified by the same root CA, and I can connect to that one via v16 (as long as the supplied certificate chain does contain the root CA). According to the web browser, it uses TLS via RSA with AES 256-bit CBC, while the web server in question uses RSA with AES 128-bit GCM. So is there a chance the latter cipher suite is not supported in SQL Anywhere's OpenSSL feature?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
AHA there's your answer. No, SQLA v16 does not support GCM, only CBC. Good catch!
Ah, thanks for the clarification! (Aside: I was really irritated because I had tested v16 some months ago against another web servers certified by the same root CA, and that worked as expected... The according web server seems to be configured differently, so I have to find out whether this can be adapted...)
Hm, the case is not yet solved, unfortunately, as the according Apache 2.4 web server certainly does support AES 256-bit CBC mode (particularly OpenSSL's ciphersuites ECDHE-RSA-AES256-SHA384 and ECDHE-RSA-AES256-SHA), as tested with openssl s_client. It just prefers GCM ciphersuites like ECDHE-RSA-AES256-GCM-SHA384.
While I can easily specify the preferred ciphersuites during an openssl s_connect call, I guess there's no chance to do so for the SQL Anywhere web client, right?
SQLA16 didn't support ECHDE ciphers either. The only ciphers supported in that version are TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, and RC4-MD5 (except in FIPS mode). v17 increased the number and strength of the supported ciphers but you're right, there's no way to adjust the list.
User | Count |
---|---|
68 | |
8 | |
8 | |
6 | |
6 | |
6 | |
6 | |
6 | |
6 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.