I'm using MySQL 5.7 and I want to set up SSL to force the client to use a cert. This cert is a self-signed cert that I generate. I have the cert for both server and client being: - CA - cert - key Where the CA has the cert for server and client. I then configured the config file (mysqld.conf) to use the cert: [mysqld] ssl ssl-ca=/database/mysql/ssl/ca-cert.pem ssl-cert=/database/mysql/ssl/master-public.pem ssl-key=/database/mysql/ssl/master-private.pem And run the command to enforce it: GRANT ALL PRIVILEGES ON database TO 'user'@'192.168.10.10' IDENTIFIED BY 'password' REQUIRE SSL; I can see SSL is enabled and it's picking up the right files running the command: SHOW VARIABLES LIKE '%ssl%'; However, from the client machine (192.168.10.10. in this example) I can connect via command line without specifying any cert and it just connects. I can see the connection is using SSL with: mysql> \s SSL: Cipher in use is DHE-RSA-AES256-SHA But the idea is to allow t he connection only if I use the certs. Is there a way to enforce it to make sure it won't connect without specifying the cert ? So I can configure the application to use it and make sure other applications wouldn't access it.

I have configured Db2 v11.5.7.0 on Linux/x64 to use SSL/TLS protocol and Db2 client can successfully connect to Db2 server using SSL/TLS. Now I would like to test certificate renewal. I need to create certificate request and then sign it with company CA with limitation of "not after" some date. I would like to set only few days certificate validity, so on my testing system I can test what happens when certificate expires. I am using gsk8capicmd_64 to create certificate request. I checked official documentation , but can't figure it out. When renewing certificate request how to specify that certificate is not valid after specific date?

I have setup a MongoDB server with a self-signed server certificate, and when I use the server validation method in Compass along with the CA certificate, it works well. However, I am still able to connect to the database if I select the “unvalidated” option in Compass, and I don’t want that. I want to reject any client connections that are not validating the server certificate. Is it possible to setup the server to do that? I have requireTLS setup in the config file, but Compass still lets unvalidated connections through.

I am beginning to set up CouchDB on an Ubuntu 14.04 Server (yes, it expires next year) and I'm having troubles setting up SSL connections. For the moment, I don't have any CA signed certs for it, so I've been following the steps on the CouchDB docs . To list my changes to the config file: I have essentially kept them as the default except I set the bind address to 0.0.0.0 to be accessible over the network, and I moved my database_dir and view_index_dir to another path. For the SSL part, I followed the documentation precisely step-by-step, and restarted the couch service. From localhost, I get the response I expect: user@ubuntu:/etc/couchdb# curl -k https://127.0.0.1:6984/ {"couchdb":"Welcome","uuid":"43cf4aa1c38ef1feb9ec71ab93dddea3","version":"1.6.1","vendor":{"name":"Ubuntu","version":"14.04"}} Now, when I try to access the server over the network (which right now is just me accessing a VM from the host, having tried a bridged and host-only adapter in VBox): courtney@host:~$ curl -k https://192.168.10.38:6984/ curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to 192.168.10.38:6984 At this point, I'm not sure what I'm missing. Is the documentation inaccurate? Or perhaps some packages I'm missing? I installed couch from the PPAs

I've got my standard MariaDB database with phpMyAdmin. I'm working with OpenSSL and php. And I've got nothing more than a basic rented web-server. $cipher_algo = 'aes-128-cbc'; $key = '2IZVjWzP5jebqU2LtGdQsyM937OIOdvY'; $iv_length = openssl_cipher_iv_length($cipher_algo); $iv = openssl_random_pseudo_bytes($iv_length); $options = 0; //base 64 encoded string $toCipher = "text to crack"; $encrypted = openssl_encrypt($toCipher, $cipher_algo, $key, $iv_length, $iv); $deCrypted = openssl_decrypt($encrypted, $cipher_algo, $key, $iv_length, $iv); 1) - I've got my text that I encrypt: the encrypted text. 2) - I've got the Initialisation Vector (IV) that I also store in a DB. 3) - The Key to (de)crypt the text with the IV. The Key: I can store that in an .environment file above the server root. I don't want to put the encrypted text and the IV next to each other in the same table, for obvious reasons. So I'm thinking with the means that I have: a different Database, in unfortunately the same server. BUT: I can use an elaborate unique value to link the IV to the encrypted text. And I could encrypt these unique values so that they don't appear the same when you place the tables next to each other. But if the database is hacked and somebody is looking through it. Than who cares how magical and unique these values are. Entry 1 in the first database probably links up to entry 1 on the second database. And entry 2 in DB1 with entry 2 in DB2. and so on. So what is a propper way to mismatch entry fields in different tables/databases? OR, what are my other options?

Recently, I was asked to apply SSL certs to SQL. After a bit of research, I found an article to add the server cert to SQL using the SQL Server Configuration Manager. When the server cert expires our PKI admin has it to auto update within the system via powershell script, our server certs are generated via MS CA and the name of the cert remains consist ex Server1.domain.crt - which i use in the SQL Cert settings My question, when the cert expires and is replaced will it also be reflected in SQL? If not is there a way to automate updating to the new cert?

i setup my postgresql in container, with hostssl and clientcert=verify-full as an option. I already generate root CA, then sign both server-key.pem and server.pem. then I sign client-key.pem and client.pem using the root CA. Now I try to connect using psql:

$ psql "host=0.0.0.0 port=5433 dbname=mydb user=mydb password=mpdb sslmode=verify-full sslcert=./docker/volumes/db/certs/server.pem sslkey=./docker/volumes/db/certs/server-key.pem sslrootcert=./docker/volumes/db/certs/ca.pem"

I'm in WSL btw. I tried with command terminal in windows too, but both is not working until now. Here's what I've done: - changing the ownership to postgres:postgres on both my container and local file - changing from server-key.pem to client-key.pem - change the file mod to both 600 to key, and 400 and also 600 to cert. Including the root CA. I'm getting this error up until now: > psql: error: connection to server at "0.0.0.0", port 5433 failed: could not load private key file "./docker/volumes/db/certs/server-key.pem": Bx�PV my hba:

hostssl    all             mydb    0.0.0.0/0            cert  clientcert=verify-full
hostnossl  all             mydb    0.0.0.0/0            reject

my conf:

listen_addresses = '*'
port = 5432

the port is map from 5433 -> 5432 on my docker compose file. I've no idea what I'm missing right now and why I have this Bx�PV in my psql error output. Any suggestion?

I am using the [MySQL 5.7 SSL Setup Guide](https://dev.mysql.com/doc/refman/5.7/en/using-encrypted-connections.html) (combined with a few other guides on the website + google searches). I have a replica and source working, I am now trying to configure SSL. My understanding is that MySQL generates the certs we need on startup so I am attempting to use those. I also tried to use the certbot certs I have setup for my domains but those failed (is it possible to use certbot/letsencrypt certs here?). I am just trying to get any SSL connection at this point. I have my config files setup like so (I've tried a number of configs now)

# This is in the source
[mysqld]
ssl_ca=/var/lib/mysql/ca.pem
ssl_cert=/var/lib/mysql/server-cert.pem
ssl_key=/var/lib/mysql/server-key.pem
require_secure_transport=ON

# This is in the replica
[client]
ssl-ca=/var/lib/mysql/ca.pem
ssl-cert=/var/lib/mysql/client-cert.pem
ssl-key=/var/lib/mysql/client-key.pem

On the replica if I do mysql -u root -p I get this error: ERROR 2026 (HY000): SSL connection error: SSL_CTX_set_default_verify_paths failed Looking through the logs on my replica I see that the connection to the source is failing with error code 3159. Running mysql > status; on source I see that SSL is not in use.

I was reading this: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.SSL Step 2 says "Install the certificate in your operating system", but I am able to connect with psql without doing anything, and when I do, it says SSL connection. Without the servers certificate, how can it do this? Where are public certificates to be kept for a client to check? I've seen things talking about ~/.postgresql, others saying with the rest in /etc/ssl, but I don't see Amazon's anywhere on my system.

We are starting to get the error message The server did not preserve SSL encryption during a recovery attempt, connection recovery is not possible from our MS SQL Server 2019 15.0.4298.1 instance. We have never seen this error before, and are at a loss as to what caused it. The Microsoft documentation at https://learn.microsoft.com/en-us/sql/connect/oledb/features/idle-connection-resiliency?view=sql-server-2017 states that this is one of the errors that can occur when connection recovery is not possible, but it does not mention why connection recovery may not be possible. Also, we are starting to see this issue just recently. We "fixed" it by setting the retry attempts to 0, thus switching off connection resiliency, which works for our system. But we don't know if we just masked a deeper core problem that will bite us later. Are there any current updates or other changes that are known to create conditions where connection recovery is not possible?

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?

Am facing some below problem in my mongodb replication environment I have 3 replica set environment with SSL enabled and ssl mode as preferSSL 3 servers has 3 different Key file with common CA file when i try to connect the mongo shell with below command it works fine mongo --ssl --host hostname:port --sslPEMKeyFile "/home/mongod/keyfile.pem" --sslCAFile /home/mongod/CAfile.pem My question is how to provide these details in connection string to connect the database from application perspective MongoDB version: 4.0.2 OS: Amazon Linux Thanks, Vignesh

MariaDB Replica error. SSL certificate validation failure Master and SLave on Windows. Both on MariaDB 10.11.11. All certificates are created on OpenSSL On Slave:

Slave_IO_State: Connecting to master                    
    Master_Host: 192.168.0.20                   
    Master_User: replicator                  
    Master_Port: 3306                 
    Connect_Retry: 10                
    Master_Log_File: mysql-bin.000042            
    Read_Master_Log_Pos: 40394082                 
    Relay_Log_File: mysql-relay-bin.000001                  
    Relay_Log_Pos: 4          
    Relay_Master_Log_File: mysql-bin.000042               
    Slave_IO_Running: Connecting              
    Slave_SQL_Running: Yes                
    Replicate_Do_DB:            
    Replicate_Ignore_DB:             
    Replicate_Do_Table:         
    Replicate_Ignore_Table:        
    Replicate_Wild_Do_Table:    
    Replicate_Wild_Ignore_Table:                     
    Last_Errno: 0                     
    Last_Error:                   
    Skip_Counter: 0            
    Exec_Master_Log_Pos: 40394082                
    Relay_Log_Space: 3584                
    Until_Condition: None                 
    Until_Log_File:                  
    Until_Log_Pos: 0             
    Master_SSL_Allowed: Yes            
    Master_SSL_CA_File: C:/mariaDB/cert/ca-cert.pem             
    Master_SSL_CA_Path: 
    Master_SSL_Cert: C:/mariaDB/cert/client-cert.pem              
    Master_SSL_Cipher:                 
    Master_SSL_Key: C:/mariaDB/cert/client-key.pem          
    Seconds_Behind_Master: NULL  
    Master_SSL_Verify_Server_Cert: Yes                  
    
Last_IO_Errno: 2026                  
Last_IO_Error: error connecting to master 'replicator@192.168.0.20:3306' - 
               retry-time: 10  
               maximum-retries: 100000  
               message: SSL connection error: SSL certificate validation failure                 
Last_SQL_Errno: 0                 
Last_SQL_Error:    
Replicate_Ignore_Server_Ids:               
Master_Server_Id: 0                 
Master_SSL_Crl:             
Master_SSL_Crlpath:                     
Using_Gtid: No                    
Gtid_IO_Pos:        
Replicate_Do_Domain_Ids:    
Replicate_Ignore_Domain_Ids:                  
Parallel_Mode: optimistic                      
SQL_Delay: 0            
SQL_Remaining_Delay: NULL        
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates               
Slave_DDL_Groups: 0 
Slave_Non_Transactional_Groups: 0     
Slave_Transactional_Groups: 0           
Replicate_Rewrite_DB:

    | Variable_name       | Value                                      |
    | have_openssl        | NO                                         |
    | have_ssl            | YES                                        | 
    | ssl_ca              | C:/mariaDB/cert/ca-cert.pem                |
    | ssl_capath          |                                            | 
    | ssl_cert            | C:/mariaDB/cert/server-cert.pem            | 
    | ssl_cipher          |                                            | 
    | ssl_crl             |                                            |
    | ssl_crlpath         |                                            |
    | ssl_key             | C:/mariaDB/cert/server-key.pem             | 
    | version_ssl_library | WolfSSL 5.7.6                              |

`mysql  Ver 15.1 Distrib 10.11.11-MariaDB, for Win64 (AMD64), source revision e69f8cae1a15e15b9e4f5e0f8497e1f17bdc81a4

Connection id:          8
Current database:
Current user:           root@localhost
SSL:                    Cipher in use is ECDHE-RSA-AES256-GCM-SHA384
Current pager:          stdout 
Using outfile:          '' 
Using delimiter:        ; 
Server:                 
MariaDB Server version:         10.11.11-MariaDB-log mariadb.org binary distribution 
Protocol version:       10 
Connection:             localhost via TCP/IP Server 
characterset:    utf8mb4 Db     
characterset:    utf8mb4 Client 
characterset:    utf8mb3 Conn.  
characterset:    utf8mb3 
TCP port:               3306

Log mariadb on Slave:

[Note] Slave I/O thread: Start asynchronous replication to master 'replicator@192.168.0.20:3306' in log 'mysql-bin.000042' at position 40394082 2025-02-26 10:14:56 9 
[Note] Slave SQL thread initialized, starting replication in log 'mysql-bin.000042' at position 40394082, relay log 'C:\mariadb\log\mysql-relay-bin.000001' position: 4 
[ERROR] Slave I/O: error connecting to master 'replicator@192.168.0.20:3306' - retry-time: 10  maximum-retries: 100000  message: SSL connection error: SSL certificate validation failure, Internal MariaDB error code: 2026

Log mariadb on Master:

[Warning] Aborted connection 93919 to db: 'unconnected' user: 'unauthenticated' host: 'slave.themdall.local' (Got an error reading communication packets) 
[Warning] Aborted connection 93919 to db: 'unconnected' user: 'unauthenticated' host: 'slave.themdall.local' (This connection closed normally without authentication)

I can connect to TestDB from mysql slave on this command:

mysql --ssl-ca=C:/mariaDB/cert/ca-cert.pem --ssl-cert=C:/mariaDB/cert/client-cert.pem --ssl-key=C:/mariaDB/cert/client-key.pem -h 192.168.0.20 -p -u replicator -D TestDB

I have an instance of SQL Server Reporting Services (2019) on our intranet with a company issued SSL certificate. Our company has started supporting ACME certificates (think "Let's Encrypt", but our own intranet-based version for servers that are not exposed to the public). Has anyone tried to use ACME certificates with their SSRS? I'm not sure how it would be configured and updated. It's pretty clear-cut for IIS, but SSRS doesn't use IIS.

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 have added the following settings to my Oracle 11 server (Bolded text is the change)- sqlnet.ora- SQLNET.AUTHENTICATION_SERVICES = (**TCPS,** NTS) ----------------------------------------------------------------------------- listener.ora- SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = C:\oraclexe\app\oracle\product\11.2.0\server) (PROGRAM = extproc) ) (SID_DESC = (SID_NAME = CLRExtProc) (ORACLE_HOME = C:\oraclexe\app\oracle\product\11.2.0\server) (PROGRAM = extproc) ) ) LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1)) (ADDRESS = (PROTOCOL = TCP)(HOST = hostname)(PORT = 1521)) **(ADDRESS = (PROTOCOL = TCPS)(HOST = hostname)(PORT = 2484))** ) ) DEFAULT_SERVICE_LISTENER = (XE) ------------------------------------------------------ tnsnames.ora- XE = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = hostname)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = XE) ) ) **XESSL = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCPS)(HOST = hostname)(PORT = 2484)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = XE) ) )** EXTPROC_CONNECTION_DATA = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1)) ) (CONNECT_DATA = (SID = PLSExtProc) (PRESENTATION = RO) ) ) ORACLR_CONNECTION_DATA = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1)) ) (CONNECT_DATA = (SID = CLRExtProc) (PRESENTATION = RO) ) ) Restarted OracleService XE and OracleXETNSListener. Output of tnsping and lsnrctl status- C:\oraclexe\app\oracle\product\11.2.0\server\bin>lsnrctl status LSNRCTL for 64-bit Windows: Version 11.2.0.2.0 - Production on 18-JUL-2022 22:11:02 Copyright (c) 1991, 2014, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1))) STATUS of the LISTENER ------------------------ Alias LISTENER Version TNSLSNR for 64-bit Windows: Version 11.2.0.2.0 - Production Start Date 18-JUL-2022 22:09:15 Uptime 0 days 0 hr. 1 min. 47 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Default Service XE Listener Parameter File C:\oraclexe\app\oracle\product\11.2.0\server\network\admin\listener.ora Listener Log File C:\oraclexe\app\oracle\diag\tnslsnr\nsanark\listener\alert\log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\EXTPROC1ipc))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostname)(PORT=1521))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=hostname)(PORT=2484))) (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostname)(PORT=3010))(Presentation=HTTP)(Session=RAW)) Services Summary... Service "CLRExtProc" has 1 instance(s). Instance "CLRExtProc", status UNKNOWN, has 1 handler(s) for this service... Service "PLSExtProc" has 1 instance(s). Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service... Service "XEXDB" has 1 instance(s). Instance "xe", status READY, has 1 handler(s) for this service... Service "xe" has 1 instance(s). Instance "xe", status READY, has 1 handler(s) for this service... The command completed successfully C:\oraclexe\app\oracle\product\11.2.0\server\bin>tnsping XE TNS Ping Utility for 64-bit Windows: Version 11.2.0.2.0 - Production on 18-JUL-2022 22:12:17 Copyright (c) 1997, 2014, Oracle. All rights reserved. Used parameter files: C:\oraclexe\app\oracle\product\11.2.0\server\network\admin\sqlnet.ora Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = hostname)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) OK (20 msec) C:\oraclexe\app\oracle\product\11.2.0\server\bin> C:\oraclexe\app\oracle\product\11.2.0\server\bin>tnsping XESSL TNS Ping Utility for 64-bit Windows: Version 11.2.0.2.0 - Production on 19-JUL-2022 14:13:37 Copyright (c) 1997, 2014, Oracle. All rights reserved. Used parameter files: C:\oraclexe\app\oracle\product\11.2.0\server\network\admin\sqlnet.ora Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCPS)(HOST = hostname)(PORT = 2484)) (CONNECT_DATA = (SERVER = DEDICATED) TNS-12560: TNS:protocol adapter error Why don't I see the 2484 port open despite of adding that to the ora files? What am I missing?

I have a host containing multiple DBs and the connection to the DBs need to be SSL enabled. Since each DB has a unique wallet, I specify the wallet location in sqlnet.ora as: WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=wallet_folder/$ORACLE_UNQNAME))) This way the listener can use the correct wallet depending on the value of ORACLE_UNQNAME variable. But I have two issues with this method. 1. Since ORACLE_UNQNAME is a shell environment variable a client has no control over it. 2. Even when connecting from the same machine I have to bounce the listener after exporting ORACLE_UNQNAME value. What is the solution for such a scenario ?

I recently turn on SSL encryption using SQL server self-signed cert then I start to ponder more about 1) encryption algorithm, authentication method It seems that the encryption/hashing algorithm used depends on the SChannel negotiation between the client/server's OS. - fine. 2) key length of the self-signed cert. I tried query this select name, pvt_key_encryption_type_desc from sys.certificates ##MS_SQLResourceSigningCertificate## NO_PRIVATE_KEY ##MS_SQLReplicationSigningCertificate## NO_PRIVATE_KEY ##MS_SQLAuthenticatorCertificate## NO_PRIVATE_KEY ##MS_AgentSigningCertificate## NO_PRIVATE_KEY ##MS_PolicySigningCertificate## NO_PRIVATE_KEY ##MS_SmoExtendedSigningCertificate## NO_PRIVATE_KEY ##MS_SchemaSigningCertificate990F36EF1B3577FE5687C7465F0A5135DE9E6834## NO_PRIVATE_KEY q1) can I check if the cert use for SSL encryption is the MS_SQLAuthenticatorCertifcate ? q2) How could a SSL encryption / CERT work with "NO PRIVATE KEY" ? In all my understanding, a cert/asymmetric encryption will involved a PUBLIC key (provided in the cert) for encryption, and the owner of the cert will have its PRIVATE key for decryption ? Why is this not the case here ?

Spanking brand-new installations of: - Visual Studio 2022 Community (VS) - SQL Server 2019 Dev (SQL) - SQL Server Management Studio v18.10 (SSMS) There are no other Visual Studio or SQL Server instances or installations. I can look at my local SQL instance using SSMS but not SQL Server Profiler. I am using Server Name "." and Windows Authentication in both cases. Profiler is being launched both in SSMS and directly launched (in administrative mode or not), with the same results: SQL-related services are in these states (enabling SQL Server Browser has no effect): "Trust server certificate" does not help. I suspect the provider is extremely sloppy about the root cause of this response. (Same system environment as https://stackoverflow.com/posts/70805318/)

I am forcing encryption on my SQL Server. My intention is to reject any client connection that does not use SSL to connect. Am I on the right track? Here are my detailed steps : * makecert -r -pe -n "CN=slc02xla.company.com" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 c:\my.cer * I imported the same certificate into the trusted Root Certification Authorities Store * In SQL Server Configuration Manager, expandrf SQL Server Network Configuration, right-clicked Protocols for , and then selected Properties. * On the Certificate tab, selected the desired certificate from the Certificate drop-down menu, and then clicked OK. * On the Flags tab, selected Yes in the ForceEncryption box, and then clicked OK to close the dialog box. * Restarted the SQL Server service. Am I missing anything else?