My case: Client: Windows 10 x64. pgAdmin 4 version 8.4 (latest). Server: Cloud Azure Cosmos DB for PostgreSQL burstable, version 16. My connection string will be likes this

jdbc:postgresql://c-donhuvycluster.qs4vulsae3t7uz.postgres.cosmos.azure.com:5432/vydb?user=citus&password={your_password}&sslmode=require

Encrypted connections

This cluster enforces encrypted connections using Transport Layer Security (TLS). For information on TLS version and certificates, refer to connecting with TLS/SSL.

How to connect in case Azure Cosmos DB default force use TLS/SSL? Please guide me. I search video tutorial on YouTube but did not see. I did not know how to face with sslmode=require . My workaround: https://learn.microsoft.com/en-us/azure/cosmos-db/postgresql/howto-ssl-connection-security#applications-that-require-certificate-verification-for-tls-connectivity But Is this command support Windows OS (I can run OpenSSL with Git Bash for Windows)? , how to declare certificate it with pgAdmin v4 8.4?

I have a validation question regarding implementation of TLS 1.2. What tools, scripts, processes, etc.. can be used to validate that TLS 1.2 is working when clients, webserver, and SQL Servers are communicating between each other? Do I need to perform network packet sniffing, run traces, use process explorer? Is there a verbose option somewhere that can be turned on with logs reviewed? Note: if it makes a difference, the SQL Servers involved run a variety of versions: 2008R2, 2012, and 2014.

After upgrading a server to postgres12 / OpenSSL 1.1.1f (Ubuntu 20.04) I got tlsv1 alert protocol version error messages from a client using an old openssl 1.0.1 library supporting only tlsv1. I thought setting ssl_min_protocol_version = 'TLSv1' in **postgresql.conf** should enable the protocol allowing that client to connect. However it does not. I used nmap to check for supported protocols and found only one section with the TLSv1.2 ciphers: ➜ ~ nmap --script ssl-enum-ciphers -p 5432 127.0.0.1 Starting Nmap 7.80 ( https://nmap.org ) at 2020-09-23 22:28 CEST Nmap scan report for localhost (127.0.0.1) Host is up (0.000064s latency). PORT STATE SERVICE 5432/tcp open postgresql | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (dh 2048) - A I used this SE answer Ubuntu 20.04 - how to set lower SSL security level? to change the system default MinProtocol setting in **openssl.cnf** to TLSv1 and postgres picked up this setting (also the openssl1.0.1 client could connect with this setting): ➜ ~ sudo service postgresql restart ➜ ~ nmap --script ssl-enum-ciphers -p 5432 127.0.0.1 Starting Nmap 7.80 ( https://nmap.org ) at 2020-09-23 22:31 CEST Nmap scan report for localhost (127.0.0.1) Host is up (0.000062s latency). PORT STATE SERVICE 5432/tcp open postgresql | ssl-enum-ciphers: | TLSv1.0: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLSv1.1: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A | TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A | TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (dh 2048) - A For curiosity I changed ssl_min_protocol_version = 'TLSv1.2' in **postgresql.conf** to see if the postgres server uses the intersection of the two configured ranges and after some debugging help from Laurenz i found that this setting was applied. My question remained: How can I configure my system so that postgres will accept TLSv1 through TLSv1.2 connections while keeping the openssl default MinProtocolsetting of TLSv1.2?

I'm setting up a MongoDB server, and wanted to use TLS from a proper CA and DNS. I got a domain name and put an A record in, linking to my server. Afterwards, I applied for a SSL certificate on sectigo.com. By their instructions, I generated a key and CSR. After confirming I did indeed own the domain name they sent me two files: a signed crt file, and a ca-bundle file. I uploaded these to my server to /etc/ssl/mongodb_server and combined the signed .crt file and .key file into a pem with cat server.key server.crt | server.pem. I then filled in the mongod.conf file as per the documentation:

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

systemLog:
  destination: file
  logAppend: true
  verbosity: 5
  path: /var/log/mongodb/mongod.log

net:
  port: 27017
  bindIp: 
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb_server/server.pem
    allowConnectionsWithoutCertificates: true

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

security:
  authorization: enabled

I'm looking to set up my server so client's don't need a ca signed certificate to connect, as this server will mainly be an API for a piece of software to grab files from. Based on this link https://docs.mongodb.com/manual/tutorial/configure-ssl-clients/#std-label-tls-client-connection-only The client needs to just specify a tlsCAFile to validate the server's certificate. I assume this is that ca-bundle.pem I was given as it includes two certificates that I assume are a chain of ca's for my certificate? When I run: mongosh --port XXXXX --host --tls --tlsCAFile ./ca-bundle.pem after a while it comes back with: MongoServerSelectionError: unable to get issuer certificate. It is only able to connect when I specify the flag --tlsAllowInvalidCertificates, which is not good enough. I tried adding allowConnectionWithoutCertificates: true to the config, as well as adding the CAFile ca-bundle.pem, but nothing changed. I also tried connecting from multiple devices and such. My mongodb is bound to a local_ip, on which a modem router has port forwarding to the server. I'm also using IP tables to change ports to 27017. I'm able to ping my server's public IP and also dig for the DNS records. But none of this should matter as I'm able to connect if I don't validate the server's certificate. I've used openssl to check that my certificate does in fact mention my domain, and that is not expired. I'm running MongoDB on Ubuntu Server 20.04 via a conf file and systemctl. Is there some step I'm missing?

I wasn't paying attention when I was presented with the option to generate credentials for operating via SSL. Having gone through the whole process, I was advised to follow-up on installing credentials. Well, I didn't know what it was advising and I left the utility. Once I restarted the MySQL server, I was unable to log into mySQL Workbench as I had previously been able to do. This hasn't (so far) seemed to affect my logging into MySQL command line interface. So, that means I am able to tweak should I need to. Something tells me that there's settings in the user table identifying which clients can connect and from where. All of this is on one machine, where I run mySQL server and perform my client business. I don't think OS is affecting this -- my woes started once I used (what appeared to be) an automated setup to install SSL. I found references online to a MySQL utility (mysql_ssl_rsa_setup) which is supposed to be for automating SSL setup. However, when I try this, I am presented with WARNING message: mysql_ssl_rsa_setup is deprecated and will be removed in a future version. Use the mysqld server instead. I'm running MySQL version 8.0.36. I don't know how to find the mysqld server version. The specific message reported by my MySQL Workbench says: Your connection attempt failed for user 'root' to the MySQL server at localhost:3306. It goes on to give 4 things to try: 1) Check that MySQL is running on address localhost. (CHECK!) 2) Check that MySQL is reachable on port 3306. (CHECK!) 3) Check the user root has rights to connect to localhost from your address. (CHECK! I can log in via the command line MySQL shell.) 4) Make sure that you are both providing a password if needed and using the correct password for localhost connecting from the host address you're connecting from (Unsure about this one except to verify that I can log into the server using

mysql -u root -p

When I list the "variables like '%SSL%'" , I get a listing of about 30 items. "have_openssl" and "have_ssl" are both yes. "ssl_ca" is "ca.pem;" and "ssl_cert" is "server-cert.pem." Finally, "ssl_key" is "server-key.pem." "ssl_session_cache_mode" and "ssl_session_cache_timeout" are "ON" and "300" respectively. "ssl_fips_mode" is "OFF". My question: How do I undo the damage done (i.e., disable ssl)?

I have some production databases in RDS for which I have active connections and writes every minute. The current server certificates are expiring on 22nd August. I tried to update one, it takes 5 minutes and the database restarts. Are there any ways in which I can avoid this downtime of 5-10 minutes and still update the certificate?

Windows 2022, SQL Server 2022, FCI cluster with 2 physical nodes. 5 instances of SQL Server running on the FCI cluster. I need to have TLS certification running on all 5 instances of SQL Server. Can a single TLS certificate (installed on the servers) be used for all 5 instances, or does it require a single certificate for each instance?

I know similar questions have been asked. What I'm asking for are concrete instructions on what to do, or not do, for my particular installation. I have some questions that I can't find the answer to, and I need some answers before I can install Microsoft's hotfix. The goal is to disable SSL 3 on the machine by adding the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server\ - add value Enabled = 0. However this causes SqlServerAgent to not start. Running SQL Server 2008 R2 (SP3) build 10.50.6220.0 (X64). Here's Microsoft's official download to enable TLS1.2 support: [link to microsoft](https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server) The page reads *First build that supports TLS 1.2 - 10.50.6542.0*. This is higher than my build number. Does it mean the hotfix only is compatible with builds from 10.50.6542 and up? And so my build is not supported? If my build is supported, then I supposed I should install it. Then what happens next?

I have a Client who moved to TLS 1.2, which broke an app that connects to SQL Server 2017 and it got dumped on my lap. Being a Linux person all I can say is when they went back to TLS 1.1 it worked and here is the only error message I can glean in all this mess: > dbnetlib connectionopen secdoclienthandshake ssl security error When I try to connect to the SQL Server from SQL Server Management Studio, I get this error message: > Error connecting to 'hostname'. > > Login failed for user 'CORP\myaccount'. (.Net SqlClient Data Provider) > > Server Name: hostname > Error Number: 18456 > Severity: 14 > State: 1 > Line Number: 65536 > > Program Location: > > at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, Object providerInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, DbConnectionPool pool, String accessToken, Boolean applyTransientFaultHandling, SqlAuthenticationProviderManager sqlAuthProviderManager) > at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions) > at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup, DbConnectionOptions userOptions) > at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource\`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection) > at System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource\`1 retry, DbConnectionOptions userOptions) > at System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource\`1 retry, DbConnectionOptions userOptions) > at System.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource\`1 retry) > at System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource\`1 retry) > at System.Data.SqlClient.SqlConnection.Open() > at Microsoft.SqlServer.Management.SqlStudio.Explorer.ObjectExplorerService.ValidateConnection(UIConnectionInfo ci, IServerType server) > at Microsoft.SqlServer.Management.SqlStudio.Explorer.ObjectExplorerService.ConnectToServer(UIConnectionInfo connectionInfo, IDbConnection liveConnection, Boolean validateConnection) TLS 1.2 was enabled on the server that hosts SQL Server.

I am trying to setup a MongoDB with SSL/TLS enabled. I'm just wondering is there a way for clients to connect to my mongodb server without having a client certificate that would not compromise the security? (not considering --sslAllowInvalidCertificates or --tlsInsecure=true) Just like how mongodb atlas is doing it.

I have set up my mongod instance with the following config:

net:
  port: 27017
  bindIp: 0.0.0.0
  ssl:
    mode: requireSSL
    PEMKeyFile: /config/mongo.pem
    CAFile: /config/ca.pem
    allowConnectionsWithoutCertificates: true

security:
  authorization: enabled

I can connect to it fine with mongosh:

mongosh --host=":27017" --username="root" --db="mydbname" --ssl --authenticationDatabase="admin"

But when I try to connect with mongodump using the exact same options...:

mongodump --host=":27017" --username="root" --db="mydbname" --ssl --authenticationDatabase="admin"

...It fails with the message Failed: error connecting to db server: no reachable servers. Checking the mongod logs I see the following:

{"t":{"$date":"2023-12-08T13:55:30.966+00:00"},"s":"I",  "c":"NETWORK",  "id":22943,   "ctx":"listener","msg":"Connection accepted","attr":{"remote":"","uuid":"41542a35-0815-4fb7-a618-d3ecf6b21a33","connectionId":244,"connectionCount":4}}
{"t":{"$date":"2023-12-08T13:55:30.980+00:00"},"s":"W",  "c":"NETWORK",  "id":23234,   "ctx":"conn244","msg":"No SSL certificate provided by peer"}
{"t":{"$date":"2023-12-08T13:55:30.985+00:00"},"s":"I",  "c":"NETWORK",  "id":22944,   "ctx":"conn244","msg":"Connection ended","attr":{"remote":"","uuid":"41542a35-0815-4fb7-a618-d3ecf6b21a33","connectionId":244,"connectionCount":3}}

These three lines are repeated several times until the connection times out. I'm wondering why it says No SSL certificate provided by peer when I have allowConnectionsWithoutCertificates set to true. It obviously doesn't seem to be a problem when using mongosh as it connects without a problem.

We have migrated the application databases from an old SQL Server 2000 instance running on Windows 2003 to a new SQL Server 2022 instance running on Windows 2022. The application tier has a number of web servers using IIS 6.0 on Windows 2003 and when they try to test the connection to the new SQL Server they get the below SSL security error. Any idea what could be the issue is here, is it likely to be the driver(screenshot below shows drivers installed on the web servers)? Or is it likely to be related to what versions of SSL/TLS are enabled on either side?

When I add ssl-verify-server-cert to a [client-mariadb] section in the configuration files, the client correctly verifies the server certificate when connecting to a remote MariaDB instance. When attempting to login on the client itself via localhost, however, login fails with a TLS validation error: mariadb -u root -v ERROR 2026 (HY000): TLS/SSL error: Validation of SSL server certificate failed Removing ssl-verify-server-cert allows logging in from localhost normally. How can I enable server certificate verification when connecting to a remote host, but not when connecting via localhost? I presume the error is because localhost is not the domain in the certificate on the client machine. But I also feel that adding localhost as a Subject Alt Name is probably not a good idea. Is there a solution or recommended practice for this?

I have been puzzled by this issue for almost 1 week. Hopefully someone in our community has experienced the same issue and already found a solution. So here is my problem: As per our company policy, we want database mail to be able to send emails over port 25 with TLS 1.2 enabled and with TLS 1.0 & TLS 1.1 disabled. Our mail server is Exchange Server 2010, our SQL Server 2016 (Developer and Enterprise editions) boxes have OS of Windows Server 2016 Standard editions. Our SQL Server version is: select @@version ---------------------------------------- Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) Dec 22 2017 11:25:00 Copyright (c) Microsoft Corporation Developer Edition (64-bit) on Windows Server 2016 Datacenter 10.0 (Build 14393: ) (Hypervisor) We have the DB mail configuration as shown here. The issue is whenever we turn on SSL use msdb exec dbo.sysmail_update_account_sp @account_id=2, @enable_ssl = 1; We CANNOT send db mail (no matter whether our SMTP authentication is Windows Authentication, Basic authentication or Anonymous Authentication). The error message in db mail log is as follows: > Message > > The mail could not be sent to the recipients because of the > mail server failure. (Sending Mail using Account 2 > (2018-07-30T10:52:41). Exception Message: Cannot send mails to mail > server. (Failure sending mail.). ) But if we turn off this SSL, there is no problem for db mail sent out. So how can we enable SSL and uses TLS 1.2 for db mail? I have enabled TLS 1.2 by adding registry as shown below The details is from this link (see the FAQ section)

One of our SSRS reports loads images from external sources and one of these sources has been locked down to tls 1.2 (which is fair and we're expecting more of our clients to be doing this in the future) The tls 1.2 update has been applied to the server holding the ReportServer database and the two Reporting Services endpoints held on seperate machines. All three machines have been tested locally and can all load the secured image in their browsers but when a report is ran using SSRS it fails I've set up a report for testing which has no database connection, it is simply a non secured image link and a tls 1.2 secured image link, The error I get is: Warning [rsInvalidImageReference] The ImageData for the image ‘Image2’ is invalid. Details: The request was aborted: Could not create SSL/TLS secure channel. This leaves the image as src(unknown) in the actual report So I feel like I've missed something in the installation of the tls 1.2 patch Anyone have any ideas what might be going on?

I've generated a handful of certificates for my MySQL 8.0.30 (mysql-server.x86_64 8.0.30-1.module+el8.6.0+16523+5cb0e868 @rhel-8-for-x86_64-appstream-rpms) on RHEL 8.7 and I'm running into an issue... I have my ca.pem which contains the root and intermediate certificates, server-key.pem which contains the RSA key (BEGIN RSA PRIVATE KEY/END RSA PRIVATE KEY) and server-cert.pem which contains the actual server certificate. I'm getting the following error when I start up MySQL:

2023-03-19T11:36:56.572166Z 0 [Warning] [MY-013595] [Server] Failed to initialize TLS for channel: mysql_main. See below for the description of exact issue.
2023-03-19T11:36:56.572209Z 0 [Warning] [MY-010069] [Server] Failed to set up SSL because of the following SSL library error: SSL_CTX_set_tmp_dh failed
2023-03-19T11:36:56.641677Z 0 [Warning] [MY-011302] [Server] Plugin mysqlx reported: 'Failed at SSL configuration: "SSL context is not usable without certificate and private key"

I don't know what I'm doing wrong... anyone?

I have implemented oracle wallet using orapki utility following this guide : https://stackoverflow.com/questions/63834638/how-to-change-protocol-for-oracle-database-connection-in-asp-net-core However, when I try to connect from the App Server to the database using the TCPS Protocol on non-default port 1531, I am getting the following error :

SQL*Plus: Release 12.1.0.2.0 Production on Fri Dec 23 10:30:23 2022
Copyright (c) 1982, 2014, Oracle.  All rights reserved.
Enter password:
ERROR:
ORA-28759: failure to open file
Enter user-name:

Is it the database user that I am trying to connect as need the permission on the db server wallet files? Does it need permission on the entire wallet folder or something else? I found nothing in the trace folder currently oracle user own the wallet folder: /oracle/apps/product/19.3.0.0/db/owm/wallets/oracle

Database :
Oracle 19c on Linux 7

App Server :
Windows Server 2016 with Oracle Client 12.1

Are there updates to SQLSRV32.DLL driver to support TLS 1.2? Version 10.00.18362 seems to broker a successful #TLS 1.2 handshake to #SQLServer 2016 https://sqlvandalism.com/2017/03/22/what-client-provider-am-i-using-to-connect-to-sql-server/ (near the end)

I have configured SSL/TLS on Db2/Linux v11.5.7.0. In DBeaver 22.1.5 (Java GUI program to access database) in *Driver properties* I have configured parameter: sslConnection to true and DBeaver successfully connects to Db2 user using SSL/TLS. According to Db2 Java Driver documentation in DBeaver at *Driver properties* I have configured sslClientHostnameValidation to BASIC to enable Db2 client to execute hostname validation. When I double click to establish connection in DBeaver I get error: > [jcc][t4][4.31.10] Connection failed: could not > establish a SSL connection with the server. The connection has been > configured to use hostname validation and the servers TLS certificate > does not contain a hostname or IP address which matches the value > configured by the client. ERRORCODE=-20576, SQLSTATE=08001 To troubleshoot the problem, in DBeaver I enabled *Connection calls* trace and the output is: > [jcc][Time:2022-09-01-13:32:11.588][Thread:Connect to > 'test1ssl_hostname_validation'][Connection@1fcbbce6]doHostnameValidation > () called [jcc][Time:2022-09-01-13:32:11.588][Thread:Connect to > 'test1ssl_hostname_validation'][Connection@1fcbbce6]doHostnameValidation > () returned sslIsHostnameValid=false It does not tell anything about what was the hostname it checked. I have read Db2 documentation Troubleshooting hostname validation at the client when negotiating a TLS connection and according to documentation error should be logged into db2diag.log at Db2 server site. But there is no error at all recorded in my case. I have even increased DIAGLEVEL dbm cfg parameter to maximum 4 and restarted the instance, reproduced the problem, but still no error is displayed in db2diag.log For certificate I have double check Subject Alternative Name and there is correctly set FQDN. How can I verify which hostname did client recognized and which hostname did it get from certificate? Regards

Connecting to the SQL Server (2008 R2 SP3 - KB 4057113) with SSMS version 18 yields: A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - An existing connection was forcibly closed by the remote host.) (.Net SqlClient Data Provider) ------------------------------ For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=10054&LinkId=20476 ------------------------------ Error Number: 10054 Severity: 20 State: 0 Connection failure logging is enabled on the server but nothing gets logged. Please note the for help link is dead. I've tried various database applications. Nothing gets through. The problem appears to be on the server, not the workstation, but other workstations can connect to the server. This workstation can also connect to other servers. I've got a good guess this is somehow TLS related, because that's what it was last time (server didn't support TLS 1.2 and needed a patch). This time I can't find the problem though.