Can I setup Public-Key-Pins when I setup a cronjob to renew the LetsEncrypt certificate every 30 days?
If the certificate is renewed then the Public-Key-Pin is also renewed right?
I've setup ispconfig3 on my debian six server, and here is a little smtp over ssl:
The server is postfix
AUTH PLAIN (LOL!)
235 2.7.0 Authentication successful
MAIL FROM: [email protected]
250 2.1.0 Ok
RCPT TO: [email protected]
RENEGOTIATING
depth=0 /C=AU/ST=NSW/L=Sydney/O=Self-Signed Key! Procees with caution!/OU=Web Hosting/[email protected]
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=AU/ST=NSW/L=Sydney/O=Self-Signed Key! Procees with caution!/OU=Web Hosting/[email protected]
verify return:1
DATA
554 5.5.1 Error: no valid recipients
but, the thing is, if I just do a vanilla telnet over port 25 I can authenticate and send mail like a madman... hopefully this is enough information! (as opposed to 'mail.app can't handle ssl!')
This is a technical deep dive after this overview question was asked.
What are the protocol differences between SSL and TLS?
Is there really enough of a difference to warrant a name change? (versus calling it "SSLv4" or SSLv5 for the newer versions of TLS)
Is TLS the "new" version of SSL? What features does it add, or security issues does it address?
Can anything that supports SSL support TLS? What would be involved in making the switch? Is the switch worth it?
Why is it that emails are sent over "Opportunistic TLS" and VPN's often called SSL VPN? Is there a difference in the technology, perhaps creating room for a "TLS VPN" product line ?
We have an Exchange 2007 server running on Windows Server 2008. Our client uses another vendor's mail server. Their security policies require us to use enforced TLS. This was working fine until recently.
Now, when Exchange tries to deliver mail to the client's server, it logs the following:
A secure connection to domain-secured domain 'ourclient.com' on connector 'Default external mail' could not be established because the validation of the Transport Layer Security (TLS) certificate for ourclient.com failed with status 'UntrustedRoot. Contact the administrator of ourclient.com to resolve the problem, or remove the domain from the domain-secured list.
Removing ourclient.com from the TLSSendDomainSecureList causes messages to be delivered successfully using opportunistic TLS, but this is a temporary workaround at best.
The client is an extremely large, security-sensitive international corporation. Our IT contact there claims to be unaware of any changes to their TLS certificate. I have asked him repeatedly to please identify the authority that generated the certificate so that I can troubleshoot the validation error, but so far he has been unable to provide an answer. For all I know, our client could have replaced their valid TLS certificate with one from an in-house certificate authority.
Does anyone know a way to manually inspect a remote SMTP server's TLS certificate, as one can do for a remote HTTPS server's certificate in a web browser? It could be very helpful to determine who issued the certificate and compare that information against the list of trusted root certificates on our Exchange server.