The SSL certificate contains a common name (CN) that does not match the hostname.
I'm after a bit of assitance for the WAC 2025 deployed in Azure. The fundamentals are setup, and I can add standalone servers, however when I add the hyper v cluster or the nodes underneath individually, and connect, it throws up the following error. There's a self signed cert bound to the cluster listener and verified working, but it still throws the below. I'm not sure what i'm missing. The cert is also in the personal store of the local nodes with their SAN within that same certificate bound to the listener. cluster.domain.com node1.domain.com node2.domain.com Connecting to remote server name.domain.com failed with the following error message : The server certificate on the destination computer (name.domain.com:5986) has the following errors: The SSL certificate contains a common name (CN) that does not match the hostname. For more information, see the about_Remote_Troubleshooting Help topic.Lesson Learned #522: Troubleshooting TLS and Cipher Suites with Python connecting to Azure SQL DB
A few days ago, we were working on a service request where our customer was experiencing several issues connecting to Azure SQL Database due to TLS version and cipher suite mismatches when using Python and ODBC Driver 18. Although we were able to get that information through a network trace, I would like to share things that I learned. Using the library SSL in Python allows to establish a TLS/SSL context where I can control the TLS version and specify or inspect the cipher suite. Here’s a small script that demonstrates how to connect to the Azure SQL Gateway over port 1433 and inspect the TLS configuration: import ssl import socket #ServerName to connect (Only Gateway) host = 'servername.database.windows.net' port = 1433 # TLS context context = ssl.create_default_context() print("Python uses:", ssl.OPENSSL_VERSION) context.minimum_version = ssl.TLSVersion.TLSv1_2 context.maximum_version = ssl.TLSVersion.TLSv1_2 context.check_hostname = True context.verify_mode = ssl.CERT_REQUIRED context.load_default_certs() # Testing the connection. with socket.create_connection((host, port)) as sock: with context.wrap_socket(sock, server_hostname=host) as ssock: print("TLS connection established.") print("TLS version:", ssock.version()) print("Cipher suite:", ssock.cipher()) # CN (Common Name) cert = ssock.getpeercert() try: cn = dict(x[0] for x in cert['subject'])['commonName'] print(f"\n Certificate CN: {cn}") except Exception as e: print(" Error extracting CN:", e) print("Valid from :", cert.get('notBefore')) print("Valid until:", cert.get('notAfter')) Using this script I was able to: Enforce a specific TLS version by setting minimum_version and maximum_version , for example, (1.2 or 1.3) Retrieve the cipher suite negotiated. Inspect the details of the certificate. Enjoy!How to Configure and Collect Schannel and CAPI2 Logs
CAPI2 log is a diagnostic log in Windows that tracks cryptographic operations. It track events related to certificate validation, key exchange. It also record how Windows and applications use cryptographic algorithms for securing data. This is crucial for diagnosing issues with SSL/TLS, digital signatures, and other encryption-related processes. CAPI2 logs are particularly useful for diagnose security-related problems in Windows systems. When troubleshooting issues related to cryptographic operations in Windows, it may be necessary to enable and collect logs for both Schannel and CAPI2. This article will help you to configure and collect these logs for diagnostic purposes.A fatal error occurred when attempting to access the SSL server credential private key: 0x8009030d
First published on MSDN on Apr 28, 2017 Recently, I have assisted a Premier customer who installed a new certificate on Windows Server 2008 R2 but was unable to bind the certificate to the Website hosted on IIS.Designing and Implementing a PKI: Part IV Configuring SSL for Web Enrollment and Enabling Key Archival
First published on TechNet on Apr 06, 2011 The series: Designing and Implementing a PKI: Part I Design and Planning Designing and Implementing a PKI: Part II Implementation Phases and Certificate Authority Installation Designing and Implementing a PKI: Part III Certificate Templates Designing and Implementing a PKI: Part IV Configuring SSL for Web Enrollment and Enabling Key Archival Designing and Implementing a PKI: Part V Disaster Recovery Chris here again.
Exchange Hybrid SSL Certificate Question
Hello, Would like to ask reg SSL Certificate for Hybrid. I have Exchange 2013. We have the following domains. Parent domain - domain1.com (No SMTP, Not using as email address) Other domains - domain2.com, domain3.com, domain4.com (Used as email address) Question is, do I need to add domain1.com as part of my SSL Certificate or I just need to use other domains? TIA!
Exchange 2016 Issue. Event 15021 An error occurred while using SSL configuration for endpoint
Hello My event logs on my exchange server are constantly getting hit with: Event 15021 HttpEvent An error occurred while using SSL configuration for endpoint [::]:443. The error status code is contained within the returned data. I have checked around on this issue and some of the other results or fixes of this issue don't seem to work with mine. My users are able to access OWA and ECP and I don't really notice any issues with the system. Other reports have have these troubleshooting steps: netsh http show sslcert this returns: SSL Certificate bindings: ------------------------- IP:port : 0.0.0.0:443 Certificate Hash : 0c9d535326---------------------------- Application ID : {4dc3e181-e14b------------------------} Certificate Store Name : MY Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled IP:port : 0.0.0.0:444 Certificate Hash : 760aa39d552-------------------------- Application ID : {4dc3e181-e14b-----------------------} Certificate Store Name : MY Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled IP:port : 0.0.0.0:8172 Certificate Hash : 23f927ab6ccfb---------------------------- Application ID : {00000000-0000-0000-0000-000000000000} Certificate Store Name : MY Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled IP:port : 127.0.0.1:443 Certificate Hash : 0c9d5353261e510------------------------- Application ID : {4dc3e181-e14b----------------------} Certificate Store Name : MY Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled IP:port : [::]:443 Certificate Hash : 7d8923810fce72-------------------------- Application ID : {ba195980-cd49---------------------} Certificate Store Name : MY Verify Client Certificate Revocation : Enabled Verify Revocation Using Cached Client Certificate Only : Disabled Usage Check : Enabled Revocation Freshness Time : 0 URL Retrieval Timeout : 0 Ctl Identifier : (null) Ctl Store Name : (null) DS Mapper Usage : Disabled Negotiate Client Certificate : Disabled I am assuming the last binding is the issue but when I go to IIS and check that binding for 443 * it shows my correct wildcard certificate. But this netsh command does show a different Certificate Hash from the 443 certs and they really should be the same so I am not sure why IIS is showing it that way. Should I run the netsh command and replace the certificate for the this binding to match the one that is in the other bindings?
