|
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: 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: 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. |
|
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. See this FAQ and Graeme's official answer there. As already stated below Breck's answer:
(21 Jul '21, 06:17)
Volker Barth
|
|
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. 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.
(20 Jul '21, 17:19)
Volker Barth
|
