SQL Server service breaks after adding SSL certificates in Linux - sql-server

I have set up a SQL Server database server on my Ubuntu 16 machine. To make it secure over a host network I am working on adding an SSL encryption certificate on it.
I tried following the steps as mentioned on this link ssl-encryption-mssql
But after restarting the service of SQL Server, it breaks giving the below exit code status
code=exited, status=1/FAILURE
I even tried to check the logs using journalctl -u mssql-server.service -b but it is not helpful at all. For the referrence, I am adding the screenshot of journalctl command below:
My /var/opt/mssql/mssql.conf looks something like this after following the steps from official doc.
[sqlagent]
enabled = false
[EULA]
accepteula = Y
[network]
tlscert = /etc/ssl/certs/cert.pem
tlskey = /etc/ssl/private/privkey.pem
tlsprotocols = 1.2
forceencryption = 1
EDIT-1: I further checked out the logs from /var/log/syslog, it stated the following log-
Error: 49940, Severity: 16, State: 1.Unable to open one or more of the user-specified certificate file(s). Verify that the certificate file(s) exist with read permissions for the user and group running SQL Server and found this question which seems similar, I tried the approach as told by Charles but it doesn't seem to work. Even I am using the Let's Encrypt Certificates.
EDIT-2: It is not a licensed version, could this be the reason?
How to resolve this error?

I just faced the same problem even though I followed the same steps as mentioned in the microsoft documentation. The actual problem seems to be with the permissions on the folder paths where the certificate files are located.
You can verify whether mssql user is able to connect or not using the openssl commands.
This command will do a basic verification on whether the certificates are valid or not.
sudo su - mssql -c "openssl verify -verbose -CAfile /etc/ssl/certs/mssql_ca.pem /etc/ssl/certs/cert.pem"
If you wanted to see if the combination of certificates are actually working or not (with key), you can start a openssl server service and then connect to it with another openssl client connection.
sudo su - mssql -c "openssl s_server -accept 8443 -cert /etc/ssl/certs/cert.pem -key /etc/ssl/private/privkeyrsa.pem -CAfile /etc/ssl/certs/mssql_ca.pem"
openssl s_client -connect localhost:8443
Another small correction from the documentation (I am using CA provided certificate), had to convert the key file format (might not require for you).
openssl rsa -in /etc/ssl/private/key.pem -out /etc/ssl/private/privkeyrsa.pem

Related

Error: Could not issue a Let's Encrypt SSL/TLS certificate for website demovpstest.com

I have a Linux VPS with Plesk control panel. Today, I have added one domain name [demovpstest.com] on my Linux VPS through the Plesk panel. When I am going to enable Let's Encrypt SSL Certificate for my website, I am receiving the following error.
Error: Could not issue a Let's Encrypt SSL/TLS certificate for demovpstest.com.
Details
Invalid response from https://acme-v02.api.letsencrypt.org/acme/order/68205530/1263660043
Details:
Type: urn:ietf:params:acme:error:malformed
Status: 404
Detail: No order for ID 1263660043
I've tried 2 - 3 times, but it failed. Please help me to solve this error.
This is a BUG than will be solved by Plesk, meanwhile this worked for me:
1-Connect to the Plesk server via SSH
2-Search for the JSON file which contains the Let's Encrypt order in the /usr/local/psa/var/modules/letsencrypt/orders folder:
egrep -Ril example.com /usr/local/psa/var/modules/letsencrypt/orders
/usr/local/psa/var/modules/letsencrypt/orders/c92788fed3b07d20e4ad823731285d30f0c88dcb.json
Note: replace the example.com with the name of the affected domain.
3-Remove the JSON file retrieved with the previous command:
rm /usr/local/psa/var/modules/letsencrypt/orders/c92788fed3b07d20e4ad823731285d30f0c88dcb.json
4-Reissue the Let's Encrypt certificate

Amazon DocumentDB fails to connect with error "SSL peer certificate validation failed"

I am trying to connect to our AWS DocumentDB, but it fails with the following error:
2019-12-04T17:46:52.551-0800 W CONTROL [main] Option: ssl is deprecated. Please use tls instead.
2019-12-04T17:46:52.551-0800 W CONTROL [main] Option: sslCAFile is deprecated. Please use tlsCAFile instead.
2019-12-04T17:46:52.551-0800 W CONTROL [main] Option: sslAllowInvalidHostnames is deprecated. Please use tlsAllowInvalidHostnames instead.
MongoDB shell version v4.2.1
connecting to: mongodb://insights-db-2019-08-12-18-32-13.cih94xwdmniv.us-west-2.docdb.amazonaws.com:27017/?compressors=disabled&gssapiServiceName=mongodb
2019-12-04T17:46:52.684-0800 E NETWORK [js] SSL peer certificate validation failed: Certificate trust failure: CSSMERR_CSP_UNSUPPORTED_KEY_SIZE; connection rejected
2019-12-04T17:46:52.685-0800 E QUERY [js] Error: couldn't connect to server insights-db-2019-08-12-18-32-13.cih94xwdmniv.us-west-2.docdb.amazonaws.com:27017, connection attempt failed: SSLHandshakeFailed: SSL peer certificate validation failed: Certificate trust failure: CSSMERR_CSP_UNSUPPORTED_KEY_SIZE; connection rejected :
connect#src/mongo/shell/mongo.js:341:17
#(connect):2:6
2019-12-04T17:46:52.687-0800 F - [main] exception: connect failed
2019-12-04T17:46:52.687-0800 E - [main] exiting with code 1
The command I use:
mongo --ssl --host MY_DOCUMENT_DB_HOST_AND_PORT --sslCAFile MY_KEY_PATH --username MY_USERNAME --password MY_PASSWORD
A couple troubleshooting I already tried:
Sent the exact same command and key to another Mac OS X machine on the same network --> worked fine
Uninstalled and reinstalled my mongo app mongodb-community#4.2
Try adding the rds-combined-ca-bundle.pem certificate to your Mac, I had a very similar error when trying to connect to DocumentDb using localhost through a forwarded port, the command I ran is
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain rds-combined-ca-bundle.pem
I got this command from this answer
For those hitting this issue post 2020, see the last reply in this thread: https://forums.aws.amazon.com/message.jspa?messageID=936916
Mac OS X Catalina has updated the requirements for trusted certificates. Trusted certificates must now be valid for 825 days or fewer (see https://support.apple.com/en-us/HT210176). Amazon DocumentDB instance certificates are valid for over four years, longer than the Mac OS X maximum. In order to connect directly to an Amazon DocumentDB cluster from a computer running Mac OS X Catalina, you must allow invalid certificates when creating the TLS connection. In this case, invalid certificates mean that the validity period is longer than 825 days. You should understand the risks before allowing invalid certificates when connecting to your Amazon DocumentDB cluster.
To connect to an Amazon DocumentDB cluster from OS X Catalina using the AWS CLI, use the tlsAllowInvalidCertificates parameter.
mongo --tls --host <hostname> --username <username> --password <password> --port 27017 --tlsAllowInvalidCertificates
Basically, just ignore invalid certificates.

ssl connection with tls server and letsencrypt

I try to do ssl connection for my server in c.
i have take this code : https://wiki.openssl.org/index.php/Simple_TLS_Server and I have generated certificate with certbot:
sudo certbot certonly --standalone
I have copy cert.pem and privkey.pem present in /etc/letsencrypt/live/MY_DOMAIN/ on my program directory.
but when I try to connect with curl, I get this error:
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
and my server print :
1996193792:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:../ssl/record/rec_layer_s3.c:1407:SSL alert number 48
thank you for your help !
That oversimple server does not handle a chain cert (or certs), also called intermediate, which every real CA this century requires, including LE. It is suitable only for test certs you generate yourself, or some limited environments like the intranet of a company that runs its own private CA.
Replace SSL_CTX_use_certificate_file on the cert.pem file with SSL_CTX_use_certificate_chain_file on the fullchain.pem file.
Also, SSLv23* methods have (finally!) been replaced by TLS* methods as of 1.1.0 in 2016, although the obsolete names remain as synonyms for now.

Reverse enginerring PostgreSQL database with SSL connection in SchemaSpy

When running SchemaSpy get error:
Connection failed because of the following error: "no pg_hba.conf entry for host "xxx.xxx.xxx.xxx", user "xxxx", database "xxx", SSL off"
The error occurs because the database does require an SSL connection.
Is there a way to turn on the SSL flag for a connection in SchemaSpy, I opened up the jar file but couldn't find anything. I know the PostgreSQL JDBC Driver supports SSL so this should be theoretically possible.
Otherwise if any one knows any opensource/freeware tools for reverse engineering a postgresql database with an SSL connections, that would help a lot.
Thanks.
Do it like this:
java -jar schemaSpy_5.0.0 -t pgsql -host your-host-url -db your-database-name -s your-database-schema -u your-username -p your-password -connprops "ssl\=true;sslfactory\=org.postgresql.ssl.NonValidatingFactory" -o path-to-your-output-directory -dp path-to-your-jdbc-driver-jar-file
The trick: adding some additional parameters using the -connprops option: we are setting SSL to true (ssl parameter) and we are asking the client (i.e., the driver) to unconditionally accept the SSL connection (sslfactory parameter).
Per the PgJDBC documentation, use the ssl=true option in your URL's parameters, e.g.
jdbc:postgresql://myhost/mydb?ssl=true
If the host doesn't have a valid certificate or the cert doesn't match its hostname you can disable SSL validation too.
SchemaSpy accepts a JDBC URL for the connection, so this will work fine.

Openssl : error "self signed certificate in certificate chain"

When I used openssl APIs to validate server certificate (self signed), I got following error :
error 19 at 1 depth lookup:self signed certificate in certificate
chain
As per openssl documentation, this error (19) is
"X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN: self signed certificate in
certificate chain - the certificate chain could be built up using the
untrusted certificates but the root could not be found locally."
Why this error occurs ? Any problems with my server certificate ?
You have a certificate which is self-signed, so it's non-trusted by default, that's why OpenSSL complains. This warning is actually a good thing, because this scenario might also rise due to a man-in-the-middle attack.
To solve this, you'll need to install it as a trusted server. If it's signed by a non-trusted CA, you'll have to install that CA's certificate as well.
Have a look at this link about installing self-signed certificates.
Here is one-liner to verify certificate to be signed by specific CA:
openssl verify -verbose -x509_strict -CAfile ca.pem certificate.pem
This doesn't require to install CA anywhere.
See How does an SSL certificate chain bundle work? for details and correct certificate chain handling.
If you're running Charles and trying to build a docker container then you'll most likely get this error.
Make sure to disable Charles (macos) proxy under proxy -> macOS proxy
Charles is an
HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP and SSL / HTTPS traffic between their machine and the Internet.
So anything similar may cause the same issue.
The solution for the error is to add this line at the top of the code:
process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
if you are testing your end points using Postman, just go to settings and disable "Enable SSL certificate verification"

Resources