AD Certification and HTTP HTTPS for internal sites

[Warwick_Tech]

Hi All,

 

We recently had a security sweep done and an issue highlighted was our lack of HTTPS for internal sites, things like papercut, unifi etc.

 

I never really thought it was an issue as it was all internal and only someone 'sniffing' internally would find something, but to be honest it's an area I have little knowledge in so I'm interested in encrypting as much as possible -

 

The problem is most companies and even paid support we have are reluctant to talk through the steps required to secure the internals with HTTPS.

 

I have been doing my usual research and have found you can create an internal CA on AD then push out the certificate to all your machines via GPO, but this doesn't cover the linux machines etc.

 

With things like Unifi they want a certificate for every device!

 

Anyone else made a jump to HTTPS internally? or are you happy with HTTP and mark it as 'acceptable risk'

 

Regards,

[smarties11]

Hi All,

 

We recently had a security sweep done and an issue highlighted was our lack of HTTPS for internal sites, things like papercut, unifi etc.

 

I never really thought it was an issue as it was all internal and only someone 'sniffing' internally would find something, but to be honest it's an area I have little knowledge in so I'm interested in encrypting as much as possible -

 

The problem is most companies and even paid support we have are reluctant to talk through the steps required to secure the internals with HTTPS.

 

I have been doing my usual research and have found you can create an internal CA on AD then push out the certificate to all your machines via GPO, but this doesn't cover the linux machines etc.

 

With things like Unifi they want a certificate for every device!

 

Anyone else made a jump to HTTPS internally? or are you happy with HTTP and mark it as 'acceptable risk'

 

Regards,

 

Achieving this with PaperCut is pretty staightforward (https://www.papercut.com/kb/Main/SSLWithKeystoreExplorer) - so the information is out there. Our internal domain is the same as our external, so for us we just use the wildcard certificate that we have from GlobalSign, same one we use to secure our website and external services. I use this on all our internal systems e.g. PaperCut, Ruckus Wi-Fi, Synology NAS etc.

 

It should also be fairly easy to achieve with an AD CA, as with these the root certificate is automatically pushed to clients, so therefore they will automatically trust any certificates issued by it. However, it's a bit more upkeep - ensuring you renew your root certificates etc

[Warwick_Tech]

Achieving this with PaperCut is pretty staightforward (https://www.papercut.com/kb/Main/SSLWithKeystoreExplorer)

 

Thanks for some actual instructions!

 

So in theory if I install the CA role on the AD It's pretty much 'configure and go'?

[Norphy]

I would be amazed if devices like wireless access points didn't already have self-signed SSL certificates for their management interfaces. I've not seen one that doesn't in a very long time. Yes, your PC won't trust them but traffic will still be encrypted, you'll just get a warning in your browser. Of course, I've not used Unifi before so that could be complete balderdash.

 

For internal websites, you have a choice:

 

1) Use an internal CA and push that CA's root certificate out to your clients, so that they trust it. Very easy with Windows devices, use a GPO. Easy with iOS and Macs, use a profile. Don't know with Linux, I don't know how you manage them. Worst case scenario, you'd need to manually put the Root CA certificate onto each device's trust store. Any server certificates issued by your internal CA are then trusted by the device and you can get on with your day. Advantages to this approach:

• No extra monetary cost, assuming you've got spare hardware capacity and licenses for whatever OS you're running your CA on
  
• You can issue them to any address. Public CAs will only issue certificates to resolvable DNS names that you control, so no .local etc
  
• Longer certificate life spans
  

 

Disadvantages:

• Devices need to trust your CA to stop errors from appearing in the browser.
  
• Not suitable for BYOD devices, as they won't trust your CA
  
• It's another thing you need to support
  

 

2) Get publicly signed certificates for each web service. You could get a certificate for each website, a wildcard certificate for a domain (e.g. *.domain.com or *.internal.domain.com) or a certificate with multiple Subject Alternate Names (SAN), one for each website the certificate is on. I think the limit for SANs is something like 50 per certificate. You could use a paid for CA like Gandi or LetsEncrypt. LetsEncrypt is free but certificates last three months and they don't natively support Windows, so you'd need to use Linux to get them and convert them to something a Windows server can use. You'd also have to set up some kind of automated process to renew your certificate.

Advantages to this approach:

• Devices should automatically trust a public certificate, so there's no further configuration needed on the device
  
• No errors when you try to access a site signed with a cert from a public CA
  

 

Disadvantages:

• Depending on how many websites you need to secure, it could get expensive. Using wildcards or SANs can cut this expense, but you'd need to have enough sites to make the extra cost worthwhile
  
• Could be more time consuming, especially if you use LetsEncrypt
  

 

Ultimately, you need to decide if the service that you're using needs to be encrypted or not. Using Papercut as an example, when you access the website you need to authenticate with it and that means putting your domain password into it. If the site isn't encrypted, that means entering your username and password in plain text, which isn't good. With other websites, you might not care.

[Warwick_Tech]

Ok, so I've opened a can of worms here -

 

I inherited this network and the previous NM has AD CA installed and somewhat configured, but it hasn't been working since he left -

 

The three top are the DC (still certificated)

[ATTACH=CONFIG]63131[/ATTACH]

 

But everything else is a PC we had on Windows 7 so way old

[ATTACH=CONFIG]63132[/ATTACH]

[ATTACH=CONFIG]63133[/ATTACH]

 

I assume I'm ok to delete\revoke these old certificates - Especially the one that has a service we no longer use on it!

[Norphy]

Can't see the attachments, but yes, if the certificates aren't in use you can get rid of them.

[Davit2005]

The issue with http is it's clear text jus like plain smtp, telnet, most DNS etc.

 

To be honest though I thought that you had to use a legit and registered fqdn for public signed certs i.e. not a .local or .internal , maybe I am wrong about that though, certs are not a strong point of mine????

 

https://www.globalsign.com/en/blog/certificates-for-internal-servers

Edited September 22, 2021 by Davit2005

[Norphy]

The issue with http is it's clear text jus like plain smtp, telnet, most DNS etc.

 

To be honest though I thought that you had to use a legit and registered fqdn for public signed certs i.e. not a .local or .internal , maybe I am wrong about that though, certs are not a strong point of mine????

 

https://www.globalsign.com/en/blog/certificates-for-internal-servers

 

That's right. If you try and get a public cert with a non-routable domain or for a domain that you don't own, the CA will tell you to go away and stop wasting their time.

[dhicks]

an issue highlighted was our lack of HTTPS for internal sites, things like papercut, unifi etc.

 

Which, I'm guessing, are hosted on virtual machines running on an internal server, or possibly on physical hwardware in a server room / cupboard, all plugged into a central switch. If that's the case then I'd have thought there would be little risk of traffic being incercepted between VMS all on one physical / virtual switch, so you could add a reverse proxy server, set that up with HTTPS, and access everything via the proxy server. That would give you the added advantage of remote access to your various internal applications via an HTTPS-protected connection, if you wanted.

 

For a reverse proxy server, I've used both Apache and Nginx, but I've recently been using Caddy:

 

https://caddyserver.com/

 

Written in Go, it runs on both Windows and Linux, and it automatically handles HTTPS for you, via Let's Encrypt.

[Warwick_Tech]

I think the general concensus Is I'm going to mark them as 'low risk'

 

Still interested in this AD CA though...

[computer_expert]

So in theory if I install the CA role on the AD It's pretty much 'configure and go'?

 

NO! please research it properly and plan accordingly. If you do it wrong, it can and will cause problems. More so with the recent Petit Potam vulnerability as an example.

 

Make sure all certs issued are SHA2/SHA256 otherwise web browsers will complain the certs are weak https://social.technet.microsoft.com/wiki/contents/articles/31296.implementing-sha-2-in-active-directory-certificate-services.aspx

Make sure you set a server up for just the CA and nothing else (no sticking in on a domain controller - will cause issues if you need to troubleshoot AD and remove a DC)

Use a 2 tier PKI setup (even if that means using something like OpenSSL on a linux distribution to create the root CA to save burning a windows server activation). Use the offline root CA (tier 1) to sign a cert for the online (issuing tier 2) subordinate/intermediate CA, that then hands out certs to devices.

 

I used this (now dated) guide but is a pretty good start: https://social.technet.microsoft.com/wiki/contents/articles/15037.ad-cs-step-by-step-guide-two-tier-pki-hierarchy-deployment.aspx

 

Before setting up the subordinate/intermediate CA, I would recommend setting LoadDefaultTemplates=0 in capolicy.inf to prevent the CA from issuing certs until you are ready to issue them. Example for deploying a template for an NPS server cert here

 

Please spin up a few VMs on an isolated domain and run through the guide before doing it to your live system.

 

If the PKI implementation is done well, it shouldn't cause too much grief (apart from the times you forget to renew the non automated renewals!).

[GaryPad]

I don't know if this is of any help but this PowerShell script will create a self-signed certificate (SHA256) and assign it to HTTPS (port 443) on IIS. It also exports a .CER file to the desktop which can be distributed to clients. It will also restart IIS so you might want to do it out of hours.

Obviously change the name of it from "My Certificate" to the name of your choice, and the password for importing the .CER file. A better solution is, as suggested by Norphy, a publically signed certificate.

$CertName = "My Certificate"

$CertPassword = "password"

$DefaultSite = "Default Web Site"

$PC = hostname

# Get defaults like Fully Qualified Domain Name, and Present Working Directory

$FQDN = [system.Net.Dns]::GetHostByName((hostname)).HostName;

$PWD = Get-Location | %{$_. Path };

$Destination = [Environment]::GetFolderPath("Desktop");

# Certificate location

$CertRoot = "cert:\LocalMachine\My"

# Generate encrypted password

$Password = ConvertTo-SecureString -String $CertPassword -Force -AsPlainText;

# Generate certificate

$Thumbprint = New-SelfSignedCertificate -DnsName $PC,$FQDN -CertStoreLocation $CertRoot | FL Thumbprint | Out-String | %{ "{0}" -f $_.Split(':')[1].Trim() };

# Set the friendly name for it

$Certificate = Get-Item -Path "$CertRoot\$Thumbprint"

$Certificate.FriendlyName = $CertName

# Bind to the website

Import-Module WebAdministration

$Binding = (Get-WebBinding -Name $DefaultSite | where-object {$_.protocol -eq "https"})

if($Binding -ne $null) {

Remove-WebBinding -Name $DefaultSite -Port 443 -Protocol "https"

}

New-WebBinding -Name $DefaultSite -IPAddress "*" -Protocol "https" -Port 443

(Get-WebBinding -Name $DefaultSite -Port 443 -Protocol "https").AddSslCertificate($Thumbprint, "My")

Start-Process "iisreset.exe" -NoNewWindow -Wait

# Export to the desktop

Export-Certificate -Cert Cert:\LocalMachine\My\$Thumbprint -FilePath "$Destination\$CertName.cer"

Note that if clients still attempt connection on HTTP then the server will still accept those requests. If you want to redirect all HTTP traffic to HTTPS then you will need to install the IIS URL Rewrite module (Google where to download that from) and edit the web.config file for your web site (usually somewhere within the C:\inetpub\wwwroot folder) to add in the following inside the

//configuration/system.webServer node: