Let's Encrypt SSL - Https redirects to wrong site

Discussion in 'Server Operation' started by Thomas CARTER, Jun 14, 2017.

  1. Thomas CARTER

    Thomas CARTER New Member

    Hi, just sharing...

    I have the latest Ispconfig with Lets Encrypt. I wanted to add 3 sites (let's call them one.com, two.com and three.com). For my first 2 sites in SSL no problem: on the Domaine tab I checked boxes SSL and Let's Encrypt SSL, passed to the Redirect tab and checked Rewrite HTTP to HTTPS. Everything worked. In Chrome one.com redirected to https://one.com with the little lock symbol. Two.com ok too.


    The third site (three.com) was a development site which I called three.temp.com with alias to three.com. This I clearly broke Let's Encrypt. Putting three.com or three.temp.com into Chrome redirected to two.com. I unchecked the redirection, then unchecked SSL and Let's Encrypt SSL, then cleared my Chrome cache, even tried IE. No change URL three.com always redirected to https://two.com. I rechecked the boxes etc, no change. I removed the alias and renamed the site three.com. No change.


    Eventually I Putty'd into the server. In /etc/letsencrypt/live I found folders with symbolic links to /etc/letsencrypt/archive with 3 folders containing the .pem files

    one.com

    two.com

    three.temp.com (even though I'd unchecked everything)


    I removed the 2 folders /etc/letsencrypt/live/three.temp.com and /etc/letsencrypt/archive/three.temp.com and rechecked the boxes SSL and Let's Encrypt SSL and Rewrite HTTP to HTTPS and the problem was solved: three.com now correctly redirected to https://three.com


    So what I think happened was the alias upset Let's Encrypt which created a non-valid certificate. Apparently it's normal to redirect to the first valid certificate if the requested certificate fails. Then when having removed the alias issue I tried to recheck the boxes, instead of recreating a good certificate it just reconnected to the bad one.


    If this helps anyone I'll be glad. I anyone can shed some light on the why's behind all of this that would be good.


    Regards,

    Thomas CARTER


    PS : Let's Encrypt is a real life-saver and the new-look Ispconfig is a real joy. Thanks for all the good work.
     
    ironjohn likes this.
  2. ironjohn

    ironjohn New Member HowtoForge Supporter

    Thank you for posting this Thomas CARTER!

    I made a new site as webrtc.mydomain.com, set proxypass to forward "/" to "http://internalpbxserver/", and excluded /.well-known/ for letsencrypt to work. I tried for a few hours, but Wazo wouldn't reverse proxy properly through ISPConfig on Apache. After deciding to give it up till tomorrow I found all of my sites were broken!!!

    That was around 10pm. I found your post at 11:45pm and was able to fix things by midnight.

    To clarify for future victims:

    Symptom: After setting up Apache proxypass, through a sub domain, on ISPConfig, previously working Certbot SSL sites throw certificate errors to web browsers.

    Cause: Your sites are all using the same (incorrect) certificate. It is most likely the one certbot created just before you realized things were bad. * This bug wants to be noticed by Developer Senpai *

    Fix:
    1) Verify the specific cert on a broken ssl site with a web browser. We'll assume the cert is for "badsub.domain.com".
    2) Go to ISPConfig > Sites > "badsub.domain.com" and uncheck "Let's Encrypt SSL" and "SSL". Save.
    *** Or just delete the bad site if your experiment is over. ***
    3) Log in with SSH or direct console, then "rm -r /etc/letsencrypt/live/badsub.domain.com" and "rm -r /etc/letsencrypt/archive/badsub.domain.com" (on Debian 9).
    4) Wait 1 real Earth minute. Open a fresh browser and check your previously working sites. They should all have green shields again.
    5) If you turn Let's Encrypt and SSL back on for the bad site you will have to fix it again. I tried and lost another 5 minutes of sleep to satisfy my curiosity.

    -John
     
    Last edited: Mar 21, 2018
  3. till

    till Super Moderator Staff Member ISPConfig Developer

    Just a guess, you might have miyed IP and * on your server in sites. either all sites must use * or all sites must use the IP, but don't mix it. If you mix it, then all sites that use * will get redirected to the one site which has the IP set.
     
    ironjohn and ahrasis like this.
  4. ironjohn

    ironjohn New Member HowtoForge Supporter

    That's entirely possible. All of my sites have the IP set as * at the moment, but I may have hit the drop down on yesterdays test. Is it best practice to specify the site IP with no plans for more than one server?

    Thanks for the tip! I'll be mindful of it now.
     
  5. till

    till Super Moderator Staff Member ISPConfig Developer

    I would use just * for all sites. Using the Ip is useful only when you have multiple IP addresses and ant to assign a specific IP address to just one site.
     
  6. ahrasis

    ahrasis Well-Known Member HowtoForge Supporter

    @Thomas CARTER, I think a domain or its subdomain that were going to other https site is normal if there were no LE certs issued for them.

    I also think that a sub / alias domain cannot create LE certs on its own, so my guest is, you have previously created three.temp.com as a site or possibly as alias / sub domain with vhost and obtained LE certs for it.

    Once the certs were issued for it, and they will not be deleted even if LE was disabled and the site was removed / deleted, but I however, don't think this is a cause to your problem.

    So far I am using alias / sub domains (with or without vhost), I don't think they are any problem in creating the LE certs for them.

    Just make sure you do it one by one, get main domain certs, then after you get it working, disabled LE for it, then create sub / alias domain, then enable LE for it again to include the sub / alias domain.

    At the last junction, if enabling LE failed, check its logs and try to understand and troubleshoot the reported error or post it here for discussion or help.

    Common error of using both * and ip as stated by @till should be noted and checked as well.
     
    webcooker likes this.
  7. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    till and webcooker like this.

Share This Page