Secure Webmail & Webadmin | MDaemon Technologies, Ltd.

Secure Webmail & Webadmin


  • I am using Let's Encrypt and standard email works great.  My research shows that the same certificate can be used for secure web access.  Is this correct?  I have HTTP & HTTPS enabled under Webmail.  My DNS redirect for webmail uses port 443 and for webadmin port 444.  Both connect with https:// but show, "Not Secure."

    Thanks for any help offered,

    Jay



  • My research shows that the same certificate can be used for secure web access.  Is this correct?

    Yes

    Both connect with https:// but show, "Not Secure."

    Does the browser give you a reason that its Not Secure?  What host name are you connecting to, is it supported by the certificate?  If you are connecting to https://mail.mydomain.com, then the certificate must have mail.mydomain.com listed on it. 

     


  • "The certificate is not valid"  The address bar shows, Not Secure in red and https is red with a red line through it.

    The host's name is mail.domain.com and the certificate matches.  The certificate gives no errors or warnings for standard MDaemon mail.  We were having problems with iPhones connecting until the host name was matched up to the certificate and now iPhones have no problems connecting and getting mail. 

     

    Edit:

    The mail host is mail.domain.com , but my https DNS redirect ultimately points to server2.domain.com .  Both point to the same ip address.  But, the name, server2.domain.com is the address that ends up in the browser bar after the redirect.  I am assuming that mismatch is the problem.  Can I create a second certificate with server2.domain.com and use that one for Web access?

    Jay

     


  • @Arron I recognized the problem was in DNS with using two different A records pointing to the same ip address.  Once I remove the server2.domain.com A record and set the redirects to point to mail.domain.com https became secure.

    This problem is resolved.

    Thank you for your reply Aaron,

    Jay


  • I'm glad you were able to get it worked out.  You could have also added server2.domain.com to the certificate by adding it to the list of alternate host names for the certificate.  This can be found in MDaemon under Security / Security Settings / SSL & TLS / Lets Encrypt or if you are running script outside of MDaemon, add the host name to the -AlternateHostNames list.


  • By the way: would it be possible to modify the scripts in such a way that the webmail responds to the server's LetsEncrypt check despite the "HTTP redirected to HTTPS" option being enabled? Renewing the certificate always requires changing this setting to "HTTP and HTTPS," which is inconvenient.


  • We have our webmail server setup to redirect HTTP to HTTPS and are using LetsEncrypt for the certificate.  LetsEncrypt is following the redirect on our server.

    What version of MDaemon are you using?

    LetsEncrypt does have some requirements in order for redirectcs to be followed.  From LetsEncrypt, https://letsencrypt.org/docs/challenge-types/.

    "Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443. It does not accept redirects to IP addresses. When redirected to an HTTPS URL, it does not validate certificates (since this challenge is intended to bootstrap valid certificates, it may encounter self-signed or expired certificates along the way)."

     


  • @Arron We are using the latest version of MDaemon (MDaemon Webmail HTTP Server: v23.0.1). For Webmail, we utilize LE certificates with the "HTTP redirected to HTTPS" option. However, we encounter an issue during certificate renewal. We have to switch Webmail to the "HTTP and HTTPS" option, as otherwise the challenges fail.

    Regards


  • What does the LetsEncrypt.log file show when the script runs to renew the certificate?


  • @Miroslaw Ours kept failing until I added *,*:80 under Setup > Web & IM Services > Webserver > Bind Webmail's Webserver to these IP/Ports only.

    Jay


  • @Arron In the LetsEncrypt.log file, there are entries: Error Code 400 Error Type: urn:ietf:params:acme:error:connection.

    @Jay Thank you so much, that's what I was looking for. The solution has been tested. It works!


  • Prior to making the changes suggested by Jay, did you have webmail configured to listen on port 80?

    Can you email me the letsencrypt log?  You can send it to arron.caruth@mdaemon.com


  • Before the changes, the field "Bind Webmail's Webserver to these IP/Ports only" was empty. I send the letsencrypt log to the address provided by you.


  • When the Bind webmail's webserver to these IP/Ports is empty, it listens on the ports configured under Setup / Web & IM Services / Webmail / Web Server, Run webmail server using this TCP port.  

    I received your email and I see that you have webmail configured to listen on port 80.

    The URLs listed in the LetsEncrypt log are still not working.  I am not able to connect to webmail using the host names provided in the script.  This leads me to believe that when the letsencrypt script needs to be renewed that you will run into problems.

    The log shows the challenge requests to your webserver timing out.  I'm experiencing the same issue when I try to connect.  I'm also experiencing a timeout when I attempt to connect to the IP address that the host names resolves to.  

    I'm also unable to connect to your server on port 25 which should be working since the MX for your domain points to the same IP.

    Are you able to connect to webmail from outside of your network?

    Do you have a firewall in front of mdaemon?  Is the firewall setup to route traffice for the hostnames and IPs to the MDaemon server?

    Is the firewall configured to block traffic certain areas?  Or is there some other configuration in the firewall that may be blocking the traffic?

    On the MDaemon server, are you able to connect to http://localhost and get webmail?

    Are you able to connect to webmail from inside of your network using the IP or host name on the default ports?

     


  • @Arron We run webmail on default port 3000.  Don't know if this is related in any way, but even after adding bind port 80 Let's Encrypt would not update the existing certificate, nor would it create a new certificate after deleting the existing certificate.  I ended up having to delete the _LEState and MDaemon folders in MDaemon > PEM and only then did Let's Encrypt work.  I had not tried to update after doing this.  I just ran a manual update and it does not work. Any thoughts?


  • Connections on port 80 must be sent to webmail in order for letsencrypt to be able to complete the HTTP challenges.     From the internet, you must be able to go to http:// and get webmail. If you don't get a webmail login page, then the HTTP challenge for LetsEncrypt will most likley also fail. Redirects are ok and should be followed.  Here is additional information from LetsEncrypt on completing challenges which I copied from https://letsencrypt.org/docs/challenge-types/#http-01-challenge

    "HTTP-01 challenge

    This is the most common challenge type today. Let’s Encrypt gives a token to your ACME client, and your ACME client puts a file on your web server at http://yourdomain/.well-known/acme-challenge/. That file contains the token, plus a thumbprint of your account key. Once your ACME client tells Let’s Encrypt that the file is ready, Let’s Encrypt tries retrieving it (potentially multiple times from multiple vantage points). If our validation checks get the right responses from your web server, the validation is considered successful and you can go on to issue your certificate. If the validation checks fail, you’ll have to try again with a new certificate.

    Our implementation of the HTTP-01 challenge follows redirects, up to 10 redirects deep. It only accepts redirects to “http:” or “https:”, and only to ports 80 or 443. It does not accept redirects to IP addresses. When redirected to an HTTPS URL, it does not validate certificates (since this challenge is intended to bootstrap valid certificates, it may encounter self-signed or expired certificates along the way).

    The HTTP-01 challenge can only be done on port 80. Allowing clients to specify arbitrary ports would make the challenge less secure, and so it is not allowed by the ACME standard.

    Pros:

    • It’s easy to automate without extra knowledge about a domain’s configuration.
    • It allows hosting providers to issue certificates for domains CNAMEd to them.
    • It works with off-the-shelf web servers.

    Cons:

    • It doesn’t work if your ISP blocks port 80 (this is rare, but some residential ISPs do this).
    • Let’s Encrypt doesn’t let you use this challenge to issue wildcard certificates.
    • If you have multiple web servers, you have to make sure the file is available on all of them."

    If the challenge is failing, you can check the LetsEncrypt log for more information.  It will look something like this:

    Error: The challenge did not complete.

                    Host Name: yourdomain

                    Error Code: 400

                    Error Type: urn:ietf:params:acme:error:connection

                    Error Detail: yourIP: Fetching http://:fullURLtocompleteChallenge Timeout during connect (likely firewall problem)

     

    Deleting the _LEState folder completely resets all the information for LetsEncrypt, its like starting over.    What does your LetsEncrypt log file show is happening?


  • I am assuming from the log below that Let's Encrypt will not update the certificate until it has expired, correct?

    Looking for the local certificate.
    I found a certifcate from LetsEncrypt.
    The certificate is still valid for 30 days.
    Host names: mail.domain.com
    Certificate host names: mail.domain.com
    The list of alternate host names has not changed.
    A new certificate is not being requested.


  • If the list of host names has not changed, the script will not try to get a new certificate unless the current certificate has less than 30 days left before it expires.  


  • @Arron Good information to know.  Thank You!


Please login to reply this topic!