TLS - Certificate Public rooted
Problem reported by Merle Wait - 8/9/2025 at 8:16 AM
Submitted
Am a little lost.. 
Request from outside vendor wants "TLS 1.2 connection - with TLS certificate publicly rooted.
---
What I have set up on my Win20016 server is TLS default - as the Win2016 by default uses 1.2
Obviously - I missing something.. but not sure how to correct.
----
Any information / suggestions' greatly appreciated it.

Douglas Foster Replied
You should ask support to help you configure a certificate from Let's Encrypt.

The theory, and why you need a certificate with a root from a Certificate Authority.
Encryption only matters if you are talking to the right entity.   Certificates provide that confidence.   When your browser connects to https://example.com, the first thing that happens is a DNS lookup to turn the web address into an IP address.   When the connection request arrives, the remote system replies with a certificate that asserts its identity (or identities), and the browser checks to see that a name on the certificate matches the name that you were trying to reach.   This ensures that your session was not hijacked.

But a malicious actor who lures you to his site can also lie about his server's identity.   So the server's identity certificate has to have a signature from somebody else.  There are typically three certificates in the trust chain:   The server identity certificate, an intermediate certificate, and a root certificate.   The root certificate is trusted because you have installed in our your system.   When you install a DigiCert root certificate, you assert that you trust DigiCert to only issue certificates to the people who own that name, because they do due diligence to verify identity of the requester before any certificates are issued.    The server identity certificate and intermediate certificate are supposed to be returned by the remote server.   The remote server should not send the root certificate, because a root certificate is self-signed, and self-signed certificates are not trusted unless they have been pre-installed on the client system.

Despite good intentions, sometimes invalid certificates do get issued, and the browser industry has struggled with the best way to kill an invalid certificate.    Every certificate has a valid date range, and an expired certificate is always untrusted.   There have been two or three different ways specified for a browser to check for early certificate invalidation, but none of those have worked well.   So now the browser industry is trying to force everyone to use automated certificate replacement, so that they can shorten gradually certificate lifetimes down to 47 days, with an expectation that certificates will be automatically renewed every 30 days.  (The other 17 are a grace period.)  Let's Encrypt is the first automated certificate issuing system, and it is free.   SmarterMail has already integrated with Let's Encrypt, so it should also be pretty easy for you.

So your correspondent is requiring a Certificate Authority certificate for your server because he want to be certain that his server only connects to other servers that can prove their identity.
Merle Wait Replied
Thank you for clarifying.  Really appreciate the confirmation.
We do have certificate from Rapid SSL .. and it is assigned to port 25.
When try to connect to their port 25 TLS (which the cert is assigned to) .. it fails.
Will, as you suggest.. open a ticket tomorrow.  DOn't see any failures in the SMTP logs - but it certainly fails.

Thank you again, for your response
Using startTLS or TLS/SSL??
Merle Wait Replied
Default TLS from Win Server-TLS  1.2
Douglas Foster Replied
It can also involve how your certificate is loaded
  It should include the intermediate certificate.

Reply to Thread

Enter the verification text