Will letsencrypt-win-simple renewal work for SAN and redirecting non-www http to www https?

[mikebrandy]

Hi. I originally installed a Letsencrypt certificate using letsencrypt-win-simple for my domain (www.domain.com). The certificate installed correctly and I was able to go to my domain via https://www.domain.com and everything is working fine.

However, I don’t want multiple versions of my site running - http://domain.com, http://www.domain.com, https://domain.com/, and https://www.domain.com. I want to consolidate and do a 301 redirect to https://www.domain.com (this is better for Google because you can avoid duplicate content). So, what I did was add the following redirect rule in my web.config:

    <rule name="Redirect non www and non https to https://www.domain.com">
      <match url=".*" />
      <conditions logicalGrouping="MatchAny">
        <add input="{HTTP_HOST}" pattern="^domain.com$" />
        <add input="{HTTPS}" pattern="off" />
      </conditions>
      <action type="Redirect" url="https://www.domain.com/{R:0}" redirectType="Permanent"/>
    </rule>

The above rule does what I want, in that it will 301 redirect you to https://www.domain.com even if the user types in http://domain.com, http://www.domain.com, or https://domain.com. However, when I went to test https://domain.com, it gave me an error because I only installed the original Letsencrypt certificate for https://www.domain.com and not https://domain.com.

So, I then ran letsencrypt-win-simple again with the --san parameter: letsencrypt-win-simple --san
Unfortunately, when I did this, it gave me the following error:

The ACME server was probably unable to reach http://domain.com/.well-known/acme-challenge/...

I suppose the reason I got the error above was because of the redirect rule I added to my web.config (refer to the redirect rule I pasted in my web.config above) and the ACME server probably can’t reach http://domain.com because of the 301 redirect. So, I had to disable that rule and run letsencrypt-win-simple again with the --san parameter, This time, it worked. I then re-enabled that rule in my web.config after the successful installation of the SAN certificate. Everything is working fine now.

My 2 questions are:

1. Because I re-enabled the redirect rule in my web.config to 301 redirect http://domain.com, http://www.domain.com, and https://domain.com to https://www.domain.com, will the letsencrypt-win-simple renewal task in Task Scheduler be able to properly renew my certificate in 60 days? I am not sure because since I re-enabled the redirect rule, I am worried that I will get the same “The ACME server was probably unable to reach http://domain.com/.well-known/acme-challenge/…” message on the date of the renewal.

2. Is there a way for me to test an early renewal using the letsencrypt-win-simple renewal task in Task Scheduler? I don’t want to wait 60 days to see if the renewal succeeds or not. I would like to test it in the next few hours (or tomorrow if I need to wait until the next day) to see if the letsencrypt-win-simple renewal task in Task Scheduler is able to properly renew the certificate.

[Osiris]

I’m not familiair with letsencrypt-win-simple, so I can only describe the behaviour of the Let’s Encrypt server part.

The Let’s Encrypt validation service actually does “follow” redirects. So when you properly redirect http://example.com to https://www.example.com, the validation service does actually request https://www.example.com.

A problem which can interfere with the validation however is HOW you redirect. For example, if you redirect http://example.com/.well-known/acme-challenge/FoObAr to https://www.example.com/ (so WITHOUT the /.well-known/acme-challenge/FoObAr) the validation service will DENY your challenge, because it can’t access the challenge token… Because the path to the token is stripped from the URL by the redirect.

Another problem can arise if the virtualhosts all use their own webroot. So a client can put the token in the webroot for http://example.com, but the redirect goes to https://www.example.com, which has its own webroot on the server. As the token is in the wrong webroot, the webserver can’t find the token in the webroot of https://www.example.com, so it serves a 404 File not found error. Consequentely, the validation service will deny your challenge.