SA17.0.10: Error Parsing Certificate

[former_SQLA_member1694881]

Hi All,

There is SA server 12.0.1.4134 with a working database.

The server starts running the following command:

dbsrv12.exe @config_base.txt

This is the contents of the config_base.txt file:

-dt C:\\TEMP
-c 2G 
-n test_web
-x tcpip(MyIP=0.0.0.0;ServerPort=xxxx;DoBroadCast=No)
-z
-o C:\\BASE\\debuginfo.log
-oe C:\\BASE\\errorinfo.log
-xs http(Port=yyyy;MaxRequestSize=70m;LOPT=ALL,HEADERS;LOG=C:\\BASE\\WebAccsess.log),https(identity=C:\\BASE\\test.pem;port=443;MaxRequestSize=200m;LOPT=ALL,HEADERS;LOG=C:\\BASE\\WebAccsess2.log;Timeout=120)
C:\\BASE\\TEST\\Test.db -n Test

That is, access to the database is possible by HTTP and HTTPS.

In the Test.pem file there is a certificate and key for it in Base64 format:

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----

This is the certificate data, as SA 12 sees it:

SQLANY12\\BIN64\\ViewCert.exe Test.crt
SQL Anywhere X.509 Certificate Viewer Version 12.0.1.4134

X.509 Certificate
-----------------
Common Name:             *.xxx.xxx.xxx
Issuer:                  Sectigo RSA Domain Validation Secure Server CA
Serial Number:           xxd5b2411qmq975cd920a19239fd23jwu
Issued:                  Jul 14, 2020   2:00:00
Expires:                 Oct 13, 2021   1:59:59
Signature Algorithm:     RSA, SHA256
Key Type:                RSA
Key Size:                2048 bits
Basic Constraints:       Is not a certificate authority
Key Usage:               Digital Signature, Key Encipherment

Using Postman 8.8, I make a request to the SA 12 database by https:

**https://xx.xx.xx.xx/test/wstestdocuments?pbegdate=01.10.2019&pendate=05.10.2019**

The query works out normally and returns the result.

========================================================

Now I take the SA server 17.0.10.5866 and launch the database under it

dbsrv17.exe @config_base.txt

config_base.txt file has not changed. The test.pem certificate file also did not change. Test.db base tried to take both in the SA12 format and did its update. Before SA17, it does not affect the problem.

SA 17 certificate data also sees SA 12:

SQLANY17\\BIN64\\ViewCert.exe Test.crt
SQL Anywhere X.509 Certificate Viewer Version 17.0.10.5866

X.509 Certificate
-----------------
Common Name:             *.xxx.xxx.xxx
Issuer:                  Sectigo RSA Domain Validation Secure Server CA
Serial Number:           xxd5b2411qmq975cd920a19239fd23jwu
Issued:                  Jul 14, 2020   2:00:00
Expires:                 Oct 13, 2021   1:59:59
Signature Algorithm:     RSA, SHA256
Key Type:                RSA
Key Size:                2048 bits
Basic Constraints:       Is not a certificate authority
Key Usage:               Digital Signature, Key Encipherment

Using Postman 8.8, I make a request to the SA 17 database by https:

**https://xx.xx.xx.xx/test/wstestdocuments?pbegdate=01.10.2019&pendate=05.10.2019**

The HTTPS request does not work out.

In SA 17 Log, I see an error message:

I. 07/20 08:41:26. HTTPS: Received Request from xx.xx.xx.xx: 55681.
E. 07/20 08:41:26. Error Parsing Certificate.

In Postman Log, such an error message:

Error: Client Network Socket Disconnected Before Secure TLS Connection Was Established

That is, it turns out that SA 12 works with this certificate for HTTPS, and SA 17 for some reason the error occurs.

P.S. Requests to SA 17 on HTTP from Postman works without error.

**http://xx.xx.xx.xx:yyyy/test/wstestdocuments?pbegdate=01.10.2019&pendate=05.10.2019**

Problem only with HTTPS requests.

[former_SQLA_member1694881]

I found a problem why I did not work on https in SA 17. As I have already written above, only mine is in the TEST.PEM file Certificate and key to it.

I took the entire chain of certificates from my root (self-signed) and placed all these certificates in Test.pem. And only after that in SA 17 earned access via HTTPS.

--------------------------------
X.509 Certificate
-----------------
Common Name:             *.xxx.xx.xx
Issuer:                  Sectigo RSA Domain Validation Secure Server CA
Serial Number:           xxd5b2411qmq975cd920a19239fd23jwu
Issued:                  Jul 14, 2020   2:00:00
Expires:                 Oct 13, 2021   1:59:59
Signature Algorithm:     RSA, SHA256
Key Type:                RSA
Key Size:                2048 bits
Basic Constraints:       Is not a certificate authority
Key Usage:               Digital Signature, Key Encipherment


X.509 Certificate
-----------------
Common Name:             Sectigo RSA Domain Validation Secure Server CA
Country Code:            GB
State/Province:          Greater Manchester
Locality:                Salford
Organization:            Sectigo Limited
Issuer:                  USERTrust RSA Certification Authority
Serial Number:           7d5b5126b476ba11db74160bbc530da7
Issued:                  Nov 2, 2018   2:00:00
Expires:                 Jan 2, 2031   1:59:59
Signature Algorithm:     RSA, SHA384
Key Type:                RSA
Key Size:                2048 bits
Basic Constraints:       Is a certificate authority, path length limit: 0
Key Usage:               Digital Signature, Certificate Signing, CRL Signing

X.509 Certificate
-----------------
Common Name:             USERTrust RSA Certification Authority
Country Code:            US
State/Province:          New Jersey
Locality:                Jersey City
Organization:            The USERTRUST Network
Issuer:                  USERTrust RSA Certification Authority
Serial Number:           1fd6d30fca3ca51a81bbc640e35032d
Issued:                  Feb 1, 2010   2:00:00
Expires:                 Jan 19, 2038   1:59:59
Signature Algorithm:     RSA, SHA384
Key Type:                RSA
Key Size:                4096 bits
Basic Constraints:       Is a certificate authority, path length limit: 0
Key Usage:               Certificate Signing, CRL Signing
--------------------------------

That is, it turns out that SA 17 requires the entire certificate chain, while SA 12 has only a final (user) certificate.

Question: Is this a SA 17 error? And then in the SA 17 documentation, this requirement is not specified.

[VolkerBarth]

See this FAQ and Graeme's official answer there.

As already stated below Breck's answer:

With the change to OpenSSL, SQL Anywhere required the certificate file to include the root certificate, too, but I don't know whether that holds for the SAP CryptoLib, as well, which is used with 17.0.10.

[Breck_Carter]

This may help, or not (because it claims it was fixed in 17.0.10.5739 which is earlier than your build )...

2865275 - Error parsing certificate file, error code 0x0d0680a8 - SQL Anywhere
Symptom
Starting a version 17 database server with an HTTPS 
   listener (-xs HTTPS(identity=<certfile.pem>...) would fail with the error: 
Error parsing certificate file, error code 0x0d0680a8.
The same certificate works fine for web servers and version 16 database servers.
Environment
SAP SQL Anywhere 17.0
Reproducing the Issue
Create a server identity certificate in which the ENCRYPTED PRIVATE KEY 
   block appears before the CERTIFICATE block. 
   Call it C:\\temp\\test.pem.
Launch a database server with the parameter -XS HTTPS(identity=test.pem;...)
Server fails to launch with the messages:
E. 01/30 15:40:13. 'C:\\temp\\test.pem' contains an expired certificate
I. 01/30 15:40:13. Database server shutdown due to startup error
Cause
The certificate parsing gear did not expect the private key 
   to appear before the certificate.
Resolution
Fixed in 17.0.10.5739. Upgrade to this build or later.
WORKAROUND:
Edit the certificate file in a text editor.
Move the ENCRYPTED PRIVATE KEY block to the end of the file.
Save the certificate file.
The engine should start correctly.

[VolkerBarth]

According to the question, the private key block is already behind the certificate block...

With the change to OpenSSL, SQL Anywhere required the certificate file to include the root certificate, too, but I don't know whether that holds for the SAP CryptoLib, as well, which is used with 17.0.10.