ACME HTTP Validation with HTTPs redirection

I had this got this to work with this requirement for an external A host record, redirects, negate rules. It was quite complex, and, in the end, it did work. I was excited, I got ready to write this long post, then I realized, I had somehow missed the obvious. I found this post on the forms with someone having the exact same issue what amazed me the most, was how simple their solution was.

So, I tested it…

The HTTP to HTTPS redirect condition:

and this will take any HTTP request and convert them into HTTPS.  If you configured HTTP validation though this will be a problem when the request from ACME comes in to hit the backend created by the ACME plugin.

As stated by the guy, he simply made a clone of the condition, and made it a negate.

then apply it to the redirect rule…

then apply this to the http listener

Test a cert renewal… it worked

That was way simpler than I thought up. lol

Hope this helps someone.

HTTP to HTTPS redirect Sub-CA Core

The Story

One day I noticed I had configured my 2008 R2 CA server to automatically redirect to the certsrv site over HTTPS even when navigating to the root site via HTTP. There was however no URL rewrite module… and I didn’t blog about so I had to figure out…. how did I do it?! Why?….. Cause this…

Sucks, and why would you issue certificates over unsecure HTTP (yeah yeah, locked down networks don’t matter, but still, if its easy enough to secure, why not).

The First Problem

The first problem should be pretty evident from the title alone…. yeah it’s core, which means; No Desktop, no GUI tools, much of anything on the server itself. So we will have to manage IIS settings remotely.

SubCA:

Nice, and…

Windows 10:

as well install IIS RM 1.2 (Google Drive share) Why… see here

and finally connect to the sub-CAs IIS…

and

Expand Sites, and highlight the default site…

Default Settings

By default you can notice a few things, first there’s no binding for the alternative default port of 443 which HTTPS standardizes on.

Now you can simply select the same Computer based certificate that was issued to the computer for the actual Sub-CA itself.. and this will work…

however navigating to the site gave cert warnings as I was accessing the site by a hostname different than the common name, and without any SANs specified for this you get certificate errors/warnings, not a great choice. So let’s create a new certificate for IIS.

Alright, no worries I blogged about this as well

On the Windows 10 client machine, open MMC…

Certificates Snap in -> Comp -> SubCA

-> Personal -> Certificates -> Right Click open area -> All Tasks -> Advanced Operations -> Create Custom Request….

Next, Pick AD enrollment, Next, Template: Web Server; PKCS #10, Next,

Click Details, then Properties, populate the CN and SANS, Next

Save the request file, Open the CA Snap-in…. sign the cert…

provide the request file, and save the certificate…

import it back to the CA via the remote MMC cert snap-in…

Now back on IIS… let’s change the cert on the binding…

Mhmmmm not showing up in the list… let’s re-open IIS manager… nope cause…

I don’t have the key.

The Second Problem

I see so even though I created the CSR on the server remotely… it doesn’t have the key after importing… I didn’t have this issue on my initial testing at work, so I’m not exactly sure what happened here considering I followed all the steps I did before exactly…. so ok weird…I think this might be an LTSB bug (Nope Tested on a 1903 client VM) or something, it’s the only difference I can think of at this moment.

In my initial tests of this the SubCA did have the key with the cert but when attempting to bind it in IIS would always error out with an interesting error.

Which now I’ll have to get a snippet of, as my home lab provided different results… which kind of annoys the shit out of me right now. So even if you get the key with the “first method” it won’t work you get the above ever, or you simply don’t get the key with the request and import and it never shows in the IIS bindings dropdown list.

Anyway, I only managed to resolve it by following the second method of creating a cert on IIS Core.

Enabling RDP on Core

Now I’m lazy and didn’t want to type out the whole inf file, and my first attempts to RDP in failed cause of course you have to configure it, i know how on desktop version, but luckily MS documented this finally…

so on the console of the SubCA:

cscript C:\Windows\System32\Scregedit.wsf /ar 0

open notepad and create CSR on SubCA directly…

save it, and convert it, and submit it!

Save!!!! the Cert!

Accept! The Cert!

Now in cert snap-in you can see the system has the key:

and should now be selectable in IIS, and not give and error like shown above.

But first the default error messages section:

and add the new port binding:

Now we should be able to access the certsrv page securely or you know the welcome splash…

Now for the magic, I took the idea of this guy”

Make sure that under SSL Settings, Require SSL is not checked. Otherwise it will complain with 403.4.forbidden

” response from this site I sourced in my original HTTP to HTTPS redirect

So…

Creating a custom Error Page

which gives this:

and finally, enable require SSL:

Now if you navigate to http://subca you get https://subca/certsrv

No URL rewrite module required:

Press enter.. and TADA:

Summary

There’s always multiple ways to accomplish something, I like this method cause I didn’t have to install and alternative module on my SubCA server. This also always enforces a secure connection when using the web portal to issue certificates. I also found no impact on any regular MMC requests either. All good all around.

I hope someone enjoys this post! Cheers!

*UPDATE 2023* This trick caused my SubCA CA services to not start. Stating failed to retrieve CRL, this was due to any attempt to retrieve the CRL over regular HTTP to fail as those requests would redirect back to the certsrv site, but requests to the same CRL via HTTPS would work. So only implement this change if you have already edited your Offline and SubCA Certificates to have CRL’s pointing to a https based URL references.

Secure a WordPress Site with HTTPS

Intro

Well it is slowly becoming a requirement, even for a site that simply shares content and has no portal or user information… such as my site… but may as well do it now since we can get certified certificates for free!!! Wooohoooo!

So doing a bit of research….

Research

Securing WordPress

TurnKey SSL Certs

Let’s Encrypt!

Cert-Bot

TurnKey WordPress uses Debian… what version?

The Tasks

Alright so we are running Debian 8, let’s follow that cert-bot tut….

Let’s start by creating a snapshot, at this point I don’t exactly have backups running yet… I know I know… I was suppose to do Free Hypervisor Backup Part 3 where I redesign ghettoVCB’s script…. unfortunately I can only do so much and I have many projects on the run. I will get it to though, I promise!


Now with that out of the way, running Cert-Bot…
Then I ran into some errors… oopsies….


What happened?!?!
Well I was working through a lot of network redesign, and my public website, the very WordPress I was trying to get a certificate for,
had a NAT rule to get out to the internet, which is why the grabbing and running of the CertBot succeeded up until this point.
I didn’t create the NAT rule to allow HTTP traffic just yet as I was wanting to create this certificate first. Little did I know it was going to be a prerequisite
Anyway I had to update my Websites DNS record to point to my new public IP,
as well as create a NAT and security rule to allow my website to be accessible from the outside world…


I had to wait a while for DNS to replicate to other servers outside, specifically whichever ones Lets Encrypt servers use to locate and validate my requests from CertBot.
so…
after making the changes, and waiting a while I attempted to access my website from the internet again,
it was failing and then I realized my mistake was in the security rule I defined. correcting my security rule, I could access my website.
running Certbot again…

Yay, and it listed all the virtual hosts hosted by my turnkey wordpress..

then created another NAT rule to hanndle https traffic… and then the security rule…

That was literally it! CertBot made it so easy! Yay that’s a first! 😀

IIS redirect HTTP to HTTPS

The Requirement

Recently I posted about creating and using a certificate for use on and IIS website. I did this recently for my Dev to deploy his new web app, which required use of a devices camera for QR scanning purposes, well it runed out that the camera could not be used unless the app was secured with TLS (a certificate). So we created a cert and created a new secure binding.

However, it was soon pretty apparent every time I pressed the down arrow key on my browsers URL it would use the regular HTTP (at first we removed the port 80 binding which caused site unavailable issue). So after re-adding the standard port 80 binding for regular HTTP, I decided to use a rewrite rule to handle the redirection.

It wasn’t as intuitive as I thought it would be so a little google search and I was on my way…

As the source states, after you have your certificate and port binding for HTTPS, as well as one for regular HTTP.

In order to force a secure connection on your website, it is necessary to set up a certain HTTP/HTTPS redirection rule. This way, anyone who enters your site using a link like “yourdomain.com” will be redirected to “https://yourdomain.com” or “https://www.yourdomain.com” (depending on your choice) making the traffic encrypted between the server and the client side.

Below you can find the steps for setting up the required redirect:

The Source

    1. Download and install the “URL Rewrite” module.
    2. Open the “IIS Manager” console and select the website you would like to apply the redirection to in the left-side menu:iisred1
    3. Double-click on the “URL Rewrite” icon.
    4. Click “Add Rule(s)” in the right-side menu.
    5. Select “Blank Rule” in the “Inbound” section, then press “OK”:iisred2
    6. Enter any rule name you wish.
    7. In the “Match URL” section:- Select “Matches the Pattern” in the “Requested URL” drop-down menu
      – Select “Regular Expressions” in the “Using” drop-down menu
      – Enter the following pattern in the “Match URL” section: “(.*)”
      – Check the “Ignore case” box

      iisred3

    8. In the “Conditions” section, select “Match all” under the “Logical Grouping” drop-down menu and press “Add”.
    9. In the prompted window:
      – Enter “{HTTPS}” as a condition input
      – Select “Matches the Pattern” from the drop-down menu
      – Enter “^OFF$” as a pattern
      – Press “OK”

      iisred4

    10. In the “Action” section, select “Redirect” as the action type and specify the following for “Redirect URL”:https://{HTTP_HOST}/{R:1}
    11. Check the “Append query string” box.
    12. Select the Redirection Type of your choice. The whole “Action” section should look like this:iisred5

The Note

NOTE: There are 4 redirect types of the redirect rule that can be selected in that menu:
– Permanent (301) – preferable type in this case, which tells clients that the content of the site is permanently moved to the HTTPS version. Good for SEO, as it brings all the traffic to your HTTPS website making a positive effect on its ranking in search engines.
– Found (302) – should be used only if you moved the content of certain pages to a new place *temporarily*. This way the SEO traffic goes in favour of the previous content’s location. This option is generally not recommended for a HTTP/HTTPS redirect.
– See Other (303) – specific redirect type for GET requests. Not recommended for HTTP/HTTPS.
– Temporary (307) – HTTP/1.1 successor of 302 redirect type. Not recommended for HTTP/HTTPS.

  1. Click on “Apply” on the right side of the “Actions” menu.

The redirect can be checked by accessing your site via http:// specified in the URL. To make sure that your browser displays not the cached version of your site, you can use anonymous mode of the browser.

The Helping Hand

The rule is created in IIS, but the site is still not redirected to https://

Normally, the redirection rule gets written into the web.config file located in the document root directory of your website. If the redirection does not work for some reason, make sure that web.config exists and check if it contains the appropriate rule.

To do this, follow these steps:

  1. In the sites list of IIS, right-click on your site. Choose the “Explore” option:iisred6
  2. “Explore” will open the document root directory of the site. Check if the web.config file is there.
  3. The web.config file must have the following code block:
    <configuration>
    <system.webServer>
    <rewrite>
    <rules>
    <rule name=”HTTPS force” enabled=”true” stopProcessing=”true”>
    <match url=”(.*)” />
    <conditions>
    <add input=”{HTTPS}” pattern=”^OFF$” />
    </conditions>
    <action type=”Redirect” url=”https://{HTTP_HOST}/{R:1}” redirectType=”Permanent” />
    </rule>
    </rules>
    </rewrite>
    </system.webServer>
    </configuration>
  4. If the web.config file is missing, you can create a new .txt file, put the aforementioned code there, save and then rename the file to web.config.

This one, much like my Offline Root CA post is a direct copy of the source. For the same reason, I felt I had no need to re-word it as it was very well written.

Thanks Namecheap, although it would have been nice to thank the actual author who took the time to do the beautiful write up with snippets. 🙂