It's time for SSL over our email servers, please.

Discussion in 'Email' started by Violynne, Apr 30, 2014.

  1. I just wasted money on a wildcard domain certificate and I'm very disappointed. It seems to me the page regarding SSL certificates should be updated immediately with the following:
    Wildcard SSL Certificates Do NOT Cover so others won't be fooled.

    Now, since this cert won't protect email with SSL, I started digging to find out how we can place SSL on our email traffic, and this is what I come up with:

    This is the reason? Because it's not in demand? Not to be rude, but since the NSA's little spying program has been unleashed to the entire world, I believe SSL over email should be mandatory.

    I can not fathom how anyone would say "the cost doesn't outweigh the benefits", especially with the growing number of breeches we've seen in recent years.

    All it would take is ONE TIME for someone to send information they didn't want made public from my website and the unencrypted information is intercepted. ONE. TIME.

    The liability risk for this is too great for everyone involved, and to be frank, I don't see Winhost or Rapid paying damages should this information get out. Rapid only guarantees my website, not the information passed from it.

    This security hole must be plugged, so I have a proposal. Please get the staff together to determine what it will cost to offer the option to users to secure email over SSL, and the price to implement the option.


    This is important, moreso today than just a year ago.
    Last edited by a moderator: Oct 14, 2015
  2. Elshadriel

    Elshadriel Winhost Staff

    It does not cover because the certificate is installed for/on the web server, not mail server. Also, encrypting the SMTP connection with SSL will only encrypt the network link from your computer (client) to our mail servers. It does not encrypt the connection between mail relays which is necessary for email to operate, so anyone listening on those channels would be able to view your information anyways. If you're really serious about email security, then you need to look at another solution like PGP. I'm not sure if there are better solutions out there now, but it is one that I heard of over 15 years ago.

    Edit: Email over SSL/TLS was not supported at the time of this post, but is supported now. Please see this KB article on how to set it up:
    Last edited by a moderator: Mar 20, 2017
  3. Which is what I had thought the wildcard cert would cover, completing the triangle of SSL so that anything served from my web server would be read on an HTTPS protected email client. I understand that if I send email out from my mail client to "", I know it's not protected by SSL, and that's something I'm okay with. I'm just a bit paranoid when it comes to my domain and its connectivity as I would feel much better if any email coming to me (from the website) isn't going to break encryption.

    Okay, now that I have a better understanding of what's behind the scenes, I'll scrap the email idea and stick with notifications and keep their messages stored in the database for retrieval.

    Thanks for your help and have a great day. :)
  4. Well, email is a "security hole" by benefit of how it works. It was never meant to be a secure method of communication on a public network (mainly because when it was created there weren't any public networks).

    As @Elshadriel mentioned, the only way to send secure email is with a public encryption key like PGP. That way your message remains encrypted along every step of its path and on the target server until the recipient uses your key to decrypt it.


    On a side note, the NSA has been listening to you for decades. Probably for your entire life (unless you're really old). For an interesting read, check out The Puzzle Palace, which was published in 1982, long before everyone had a computer in their pocket. People who are apoplectic over what the NSA is doing now simply don't realize that they've been doing essentially the same thing forever. Only the technology has changed.

    Anyone who is really worried about the NSA reading their messages or thoughts shouldn't use email at all. Or telephones, telegrams, satellites, faxes, carrier pigeons or the pony express. Okay, maybe carrier pigeons. I don't think they've cracked that yet...
    Elshadriel likes this.
  5. I believe we're having two separate conversations because the point is still being lost.

    I'm not trying to encrypt outgoing email from I'm trying to encrypt the web server and email server connection. This option is available on most email services out there, including gmail, yahoo, and outlook.

    Web pages don't send email, Michael. System.Net.Mail's "EnableSSL" isn't about encrypting email, but the connection. This request is sent over the non-encrypted port to the SMTP server. When requested, the SMTP changes port, and begins TLS encryption of the connection. Once the web server receives this, it then sends its contents to the email server.

    Once on the server, SMTP will DNS the outgoing email address(es). If the IP address is of its own, it simply places the text stream into the mail box of the domain.

    If the IP address is not of its own, it goes out, unencrypted, to the proper SMTP server to handle the text stream.

    Again, I couldn't care less about the outgoing, I only care about SSL between the web server and the email server.

    Because a wildcard cert should cover both and The cert covers the domain, not the server.

    If my expectations aren't valid, please explain to me why.
  6. If you are using our web server and our mail server, the connection between the two is on our local network, behind our firewalls, so encrypting that short hop between two local machines would only provide security for messages from your site to your local mailbox. Is that your goal? I'm not trying to be contentious, just want to understand what you are ultimately trying to accomplish.
    It doesn't cover the server, but it has to be installed on the server, and we don't have a procedure or system in place to install and maintain customer certs on the mail servers, only on the web servers.
  7. This is pretty much what I needed to know, so I don't believe you're being contentious at all. :)

    I was under the impression our emails were going out to the internet and resolving at the SMTP server, not directly going behind a firewall. It's just unusual for me to have my .NET applications spit up errors because SSL isn't available.

    I can see why you wouldn't need to. It would be pointless, since the SMPT server is behind the firewall. I, again, just assumed the cert was being installed where it needed to so the domain was covered.

    I apologize if my attitude seemed curt.

    Thanks for your help, Michael. This made a world of difference. :)
    Michael and Elshadriel like this.
  8. No need to apologize. It's good to be passionate. ;)

Share This Page