Feature request - support self-signed certs for POPS/IMAPS
I tried submitting this through support/feedback. The response I got back suggested I wasn't being understood, so I'm going to try one more time here.
We would like to use internally-signed certificates to secure POP3S. In our environment, ManageEngine SDP is the only POP3 client we have; there is no public access. Therefore, there is no justification in forcing us to purchase a "trusted" certificate signed by an external authority just to encrypt traffic--the traffic is encrypted regardless of whether the cert is signed by a trusted CA, our private CA, or only itself. The whole point of a trusted CA is to provide some authority that the general public can rely on to validate that a service running on a specific host is what and who it claims to be. Since this is strictly a two-party transaction, there is no need to employ such an authority.
The feature I'm requesting is this: I should be able to either tell SDP to trust my specific certificate, or tell it to ignore trust altogether. The first could be done by uploading the signing cert's public key or thumbprint to ME SDP, the second would be just a simple checkbox option. We'd prefer the first option as it allows us to preserve the concept of "trust", but encryption is more important than trust in this case, and trust doesn't seem to be properly implemented here anyway.
Let me put that last bit in stronger terms: from what I can see, ME SDP's current implementation of certificate validation is *broken and insecure*. It validates that the certificate is signed by a trusted authority, but not that it matches the hostname being connected to. This defeats the purpose of a trusted CA entirely. For example: if I can intercept connections to and from "mail.yourcompany.com" on port 995, all I have to do to break encryption is load up GoDaddy.com, register any domain name at all and buy a signed SSL certificate for it. I can now do a man-in-the-middle attack where SDP will cheerfully accept my "hacking-is.fun" signed cert and give up its login credentials and whatever other information I can scrape from the POP3S stream. (I'm basing this observation on the fact that we currently have SDP configured to connect to our server by IP, not hostname. The IP address is not listed in the certificate and does not resolve to any hostname in our domain, yet ME SDP connects just fine. testconnectivity.microsoft.com correctly rejects the connection for exactly this reason, unless "Ignore Trust for SSL" is checked).
We would like to use internally-signed certificates to secure POP3S. In our environment, ManageEngine SDP is the only POP3 client we have; there is no public access. Therefore, there is no justification in forcing us to purchase a "trusted" certificate signed by an external authority just to encrypt traffic--the traffic is encrypted regardless of whether the cert is signed by a trusted CA, our private CA, or only itself. The whole point of a trusted CA is to provide some authority that the general public can rely on to validate that a service running on a specific host is what and who it claims to be. Since this is strictly a two-party transaction, there is no need to employ such an authority.
The feature I'm requesting is this: I should be able to either tell SDP to trust my specific certificate, or tell it to ignore trust altogether. The first could be done by uploading the signing cert's public key or thumbprint to ME SDP, the second would be just a simple checkbox option. We'd prefer the first option as it allows us to preserve the concept of "trust", but encryption is more important than trust in this case, and trust doesn't seem to be properly implemented here anyway.
Let me put that last bit in stronger terms: from what I can see, ME SDP's current implementation of certificate validation is *broken and insecure*. It validates that the certificate is signed by a trusted authority, but not that it matches the hostname being connected to. This defeats the purpose of a trusted CA entirely. For example: if I can intercept connections to and from "mail.yourcompany.com" on port 995, all I have to do to break encryption is load up GoDaddy.com, register any domain name at all and buy a signed SSL certificate for it. I can now do a man-in-the-middle attack where SDP will cheerfully accept my "hacking-is.fun" signed cert and give up its login credentials and whatever other information I can scrape from the POP3S stream. (I'm basing this observation on the fact that we currently have SDP configured to connect to our server by IP, not hostname. The IP address is not listed in the certificate and does not resolve to any hostname in our domain, yet ME SDP connects just fine. testconnectivity.microsoft.com correctly rejects the connection for exactly this reason, unless "Ignore Trust for SSL" is checked).