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.
