Intranet Certificate Monitoring with CertKit

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.

← Back

Thank you for your response. ✨

Additional Information

CertKit Website

What Is CertKit?

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

DirectAccess Network Location Server Guidance

Introduction

The Network Location Server (NLS) is a critical component in a DirectAccess deployment. The NLS is used by DirectAccess clients to determine if they are inside or outside of the corporate network. If a DirectAccess client can connect to the NLS, it must be inside the corporate network. If it cannot, it must be outside of the corporate network. It is for this reason that the NLS must not be reachable from the public Internet. A client configured for DirectAccess will probe the NLS when it first starts, and on subsequent network interface status changes.

What is the NLS?

The NLS itself is nothing more than a web server with an SSL certificate installed. Beginning with Windows Server 2012, the NLS can be collocated on the DirectAccess server itself. Although there may be scenarios in which this is acceptable, it is generally recommended that NLS be configured on a server dedicated to this role.

NLS Configuration

Any web server can be used, including IIS, Apache, Nginx, Lighttpd, and others. You can also use an Application Delivery Controller (ADC) like the F5 BIG-IP Local Traffic Manager (LTM), as described here. The web server must have a valid SSL certificate installed that includes a subject name that matches the NLS FQDN (e.g. nls.corp.example.com). The DNS record for the NLS must configured using an A host record. A CNAME DNS entry will not work. In addition, the NLS must also respond to ICMP echo requests.

DirectAccess Network Location Server Guidance

DirectAccess Network Location Server Guidance

The certificate can be issued by an internal PKI or a public third-party Certificate Authority (CA). A self-signed certificate can be used if the certificate is distributed to all DirectAccess clients and servers, but this is not advisable. To avoid possible service disruptions, the NLS should be made highly available by deploying at least two NLS in a load balanced configuration.

What Happens if the NLS is Offline?

If the NLS is offline for any reason, remote DirectAccess clients will be unaffected. However, DirectAccess clients on the internal network will mistakenly believe they are outside of the corporate network and attempt to establish a DirectAccess connection. If the DirectAccess server is not accessible from the internal network, the client will be unable to connect to any local network resources by name until the NLS is brought online or other actions are taken.

Collocation Issues

As mentioned previously, it is possible in some scenarios to collocate the NLS on the DirectAccess server. This is probably acceptable for proof-of-concept deployments, but any production deployment should have the NLS configured on a server dedicated to this role. If the NLS is located on the DirectAccess server and the server is offline for any reason, DirectAccess clients on the internal network will be unable to access local resources by name until the DirectAccess server is back online.

Don’t Use Existing Web Application Servers

Occasionally I will encounter a scenario in which an administrator who wants to avoid implementing additional infrastructure will use an existing internal web application server for the NLS, such as a SharePoint server. Although this will work, it quickly becomes an issue when remote DirectAccess clients need to access the server. Since the NLS is not resolvable or reachable externally, connectivity will fail, preventing DirectAccess clients from reaching the internal application.

Summary

The NLS is a vitally important piece of the DirectAccess architecture. DirectAccess clients use the NLS to determine their location, and if the service is unavailable for any reason (planned or unplanned) internal DirectAccess clients will be negatively affected. The NLS isn’t necessarily complicated, as it is nothing more than a web server with an SSL certificate installed. However, don’t overlook the importance of this service, and make sure it is highly available to avoid any potential network connectivity issues.

Additional Resources

DirectAccess Network Location Server (NLS) Deployment Considerations for Large Enterprises

Configure KEMP LoadMaster Load Balancer for DirectAccess Network Location Server (NLS)

Configure Citrix NetScaler for DirectAccess Network Location Server (NLS)

Configure F5 BIG-IP for DirectAccess Network Location Server (NLS)