CertKit is a cloud-based solution that automates the issuance and management of public TLS certificates. It also provides certificate monitoring and alerting for public-facing workloads. However, many organizations have internal (non-public-facing) services that also use TLS. CertKit agent v1.13.0, currently in preview, closes this gap by providing visibility into TLS certificates used by intranet resources. After installing the latest release of the agent, CertKit can now provide visibility into the status of TLS certificates for internal resources.
Intranet Monitoring
After installing or updating the CertKit agent to v1.13.0, administrators can select an internal TLS service to monitor. Follow the steps below to enable this feature.
Certificate Collection
I recommend creating a separate Certificate Collection to support intranet monitoring. In the CertKit management console, click Add Collection, enter a unique, descriptive name, and click Add Collection.
Install the Agent
Once the new collection is created, navigate to the Agents tab, select your platform, then download, install, and register the agent.
Monitor New Host
After the agent is installed and registered, navigate to the Monitoring tab and click Monitor New Host. Enter the fully qualified domain name (FQDN) of the resource and specify its TLS port. Under Host Visibility, select Internal, and then choose the agent to monitor the host from. When finished, click Monitor Host.
Note: The server running the CertKit agent does not require a TLS certificate of its own to monitor internal resources.
Monitored Hosts
CertKit can track certificates for any internal workload that uses TLS. In this example, the monitored resources include web applications, security appliances, load balancers, and HTTP CRL distribution points. The list also includes LDAPS on the domain controllers and the RDP and WinRM HTTPS services on the management workstation.
The circle next to each resource indicates its certificate status. Green indicates a healthy certificate, yellow indicates one approaching expiration, and red indicates an expired certificate or another detected issue.
Note: The RDP certificate on the management workstation appears red because it contains only the Remote Desktop Authentication EKU (1.3.6.1.4.1.311.54.1.2). It intentionally does not include Server Authentication, which CertKit currently expects when validating the service. CertKit is aware of this limitation and plans to address it in a future release.
Host Discovery
CertKit provides robust discovery for public websites but does not currently offer equivalent functionality for intranet resources. Administrators can identify internal systems listening on a specific port by using Nmap.
nmap.exe -Pn -p [port] --open [internal subnet]
For example:
nmap.exe -Pn -p 443 --open 172.16.0.0/24
Alternatively, add the -oX switch to save the output in XML format.
nmap.exe -Pn -p 443 --open 172.16.0.0/24 -oX scan.xml
The resulting Nmap XML file output can be converted to CSV format using this PowerShell code.
Summary
CertKit agent v1.13.0 extends certificate monitoring to internal TLS services, giving administrators greater visibility into certificates that were previously difficult to track. Although intranet host discovery remains a manual process, tools such as Nmap and PowerShell can help identify resources to add to the monitoring platform
Getting Started with CertKit
Need help improving certificate visibility and management across your organization? Want to automate public TLS certificate enrollment for workloads such as DirectAccess, Always On VPN, IIS, SQL, and more? I can help you assess your certificate environment, identify monitoring gaps, and develop a strategy for managing certificates across internal and public-facing workloads. Fill out the form below, and I’ll provide you with more information.
Additional Information
CerKit Agent Support for Always On VPN SSTP and DirectAccess IPHTTPS TLS Certificates
IIS TLS Certificate Deployment with CertKit
The Case for 6-Day Public TLS Certificates
DirectAccess IPHTTPS and Let’s Encrypt 6-Day TLS Certificates
Recently I wrote about 
Unlike DirectAccess, Windows 10 Always On VPN settings are deployed to the individual user, not the device. As such, there is no support for logging on without cached credentials using the default configuration. To address this limitation, and to provide feature parity with DirectAccess, Microsoft later introduced the device tunnel option in Windows 10 1709.
Recently I wrote about 
Once Windows 10 Always On VPN has been deployed in production, it may be necessary at some point for administrators to deny access to individual users or computers. Commonly this occurs when an employee is terminated or leaves the company, or if a device is lost, stolen, or otherwise compromised. Typically, this means that user accounts and computer accounts in Active Directory are disabled, and any issued certificates are revoked. However, additional steps may be required to disconnect current VPN sessions or prevent future remote connections.
Windows Server Routing and Remote Access Service (RRAS) is commonly used for Windows 10 Always On VPN deployments because it is easy to configure and manage, and it includes Microsoft’s proprietary Secure Socket Tunneling Protocol (SSTP). SSTP is a Transport Layer Security (TLS) VPN protocol that is firewall-friendly and ubiquitously available. However, a common configuration mistake can lead to failed connections.
