|
Suppose I want to set HTTPS connection. CREATE PROCEDURE secadm.fa_client_authentication( urlSpec LONG VARCHAR, certif LONG VARCHAR) URL '!urlSpec' TYPE 'HTTP:POST:text/plain' CERTIFICATE '!certif' SET 'REDIR (COUNT = 0)' ; I use the GeoTrust_Global_CA.cer-certificate. I run: call secadm.fa_client_authentication( 'https://....com.au/apitesting/...', 'file=D:\...\GeoTrust_Global_CA.cer') For SQL Anywhere Network Server Version 12.0.1.3967:
But for SQL Anywhere Network Server Version 12.0.1.3994:
What am I doing wrong from the standpoint of "Strong encryption now achieved using OpenSSL"-requirements (Engineering Case #749256)? |
|
This appears to be an implementation difference between OpenSSL and Certicom (our previous cryptographic library provider). The certificate used by the web server in question is cross-signed, which means it was signed by two root authorities rather than just one. In this case, it's signed by both GeoTrust and Equifax, and Equifax is the real root certificate. OpenSSL requires that you supply the root certificate in the chain, and the certificate you're giving (the GeoTrust one) is not the root certificate. Certicom allows you to trust any certificate in the chain and the connection will succeed, which is why things worked with the old software. I've attached the real root certificate here, which I exported from Firefox. Replacing your certificate with this one will allow the connection to succeed. Thanks. 1) Wanting to see the validity of the new certificate, I found the following bug(?):
SQL Anywhere X.509 Certificate Viewer Version 12.0.1.3994 X.509 Certificate ----------------- Country Code: US Organization: Equifax Organizational Unit: Equifax Secure Certificate Authority Internal error: 16 But:
SQL Anywhere X.509 Certificate Viewer Version 12.0.1.3994 X.509 Certificate ----------------- Common Name: GeoTrust Global CA Country Code: US Organization: GeoTrust Inc. Issuer: GeoTrust Global CA Serial Number: 23456 Issued: May 21, 2002 7:00:00 Expires: May 21, 2022 7:00:00 Signature Algorithm: RSA, SHA1 Key Type: RSA Key Size: 2048 bits Basic Constraints: Is a certificate authority, path length limit: 0 Key Usage:
(11 Dec '13, 00:26)
Ilia63
2)Next question. X.509 Certificate ----------------- Common Name: MSU Certificate Country Code: RU State/Province: MOSCOW Locality: MOSCOW Organization: MSU Organizational Unit: Programmer Issuer: MSU Certificate Serial Number: 6cde1cf266d64bca971ae9042f27996f Issued: Jun 11, 2013 15:40:00 Expires: Jun 12, 2018 15:40:00 Signature Algorithm: RSA, SHA1 Key Type: RSA Key Size: 2048 bits Basic Constraints: Is not a certificate authority Key Usage: Digital Signature, Key Encipherment, Data Eqipherment and "hand made"-Identity: -xs https(FIPS=N;PORT=82;Identity=MSU.id;Identity_Password=...) created by the createcert.exe.
(11 Dec '13, 00:31)
Ilia63
Replies hidden
1
The first is a bug in viewcert which I also found investigating this problem. It's fixed but I haven't submitted the fix yet. The second is an entirely separate problem. Can you post that as a separate question?
(11 Dec '13, 06:53)
Graeme Perrow
FYI the viewcert problem will be fixed in 12.0.1 build 4033 and 16.0 build 1760.
(11 Dec '13, 11:11)
Graeme Perrow
|
I don't know of any regressions caused by the OpenSSL switch, but that doesn't mean there aren't any. Is it possible for you to email me the details of the web service (i.e. URL and certificate) so that I can investigate? My address is [my first name].[my last name] at sap dot com.