I am trying to get my head around a problem;
Host1 is running SQL-Server 2017 on an EC2 in a private subnet in AWS.
In order to have it accessible for an external service we put a NLB in front of it thats listening on TLS while the backend-instance is configured for TCP.
The ACM-certificate put on the NLB is a wildcard certificate by AWS whereas the actual certificate on Host1 is a self-signed cert w. the "ALIAS" of the NLB registered as a "SAN" in the cert.
I tried configuring both TLS > TLS and TLS > TCP but when I try and connect to Host1 using SSMS I get a connection timeout whereas TCP > TCP works but that is not what I want since it will go unencrypted.
Running TLS all the way (TLS>TLS) isn't strictly necessary, we can terminate the encryption at the loadbalancer as long as its encrypted in transit over the Internet (i.e. TLS > TCP) but actually having "end-to-end" encryption (i.e. TLS > TLS) would be preferable.
Right now I just want to get it to work.
Checking in AWS Athena I can't see anything under "received_bytes" and "sent_bytes" when querying the NLB;
"tls_handshake_time" is also empty in the logs which seems to indicate that I don't even get through to the NLB.
Sniffing traffic from my computer to the NLB when trying to connect through SSMS shows responses from the NLB so I can't figure out why I can't see anything in Athena when querying the NLB logs.
- I've registered the ALIAS for the NLB in the cert that is toggled in SQL Server Configuration Manager
- I've allowed the serviceaccount that runs SQLSERVER access to the cert's (on localhost) private key
- I've registered SPNs for the NLBs ALIAS;
I am quite at a loss on how to figure this out and would be grateful for any help