The definition for a Public Key Infrastructures (PKIs) varies among cyber security professionals, but is generally considered a collection of components that give everything an organization needs to issue and manage X.509 digital certificates.
PKIs can be configured to provide authentication for multiple services, such as Wi-Fi, VPN, Web Apps, E-Mail and more. On-premise legacy PKI’s, like Microsoft AD CS PKI, have become obsolete in an industry rapidly migrating to the cloud. Luckily, there are better PKI solutions at a third of the cost and entirely constructed for cloud environments. SecureW2 offers a turnkey PKI solution with #1 rated last mile certificate delivery for all network devices. Learn from one of our customers how easy our PKI solution is to configure.
Why is a PKI Important?
Passwords are not good forms of authentication as they can be lost or stolen, meaning networks that use credential-based authentication are always at risk of over-the-air credential theft. Plus, credential-based authentication setups require password reset policies, which are annoying for both network administrators and end users.
Digital certificates provide better identification because they can be locked onto devices and serve as the device or user’s identity in the digital landscape. With certificates, admins can easily configure devices for certificate-based 802.1X authentication, or EAP-TLS. PKIs serve as the foundation for admins to build a certificate-based network.
Windows PKI Server Types
Windows Server 2008
While the function of certificate services has been a feature for previous iterations of Windows servers, the 2008 R2 release was the first one with a built-in AD CS certificate authority. 2008 R2 servers are common for organizations who don’t have a third party solution to verify certificates and just use a Standalone CA. With the rise in cloud-based network services though, standalone CAs might not cut it anymore for certificate services (we’ll discuss more about this further down).
Windows 2012
Windows 2012 servers support a policy that allows NDES implementation so devices have an easier way accessing the network. NDES also makes it possible for BYODs to gain network access. Windows 2012 servers also come with new Windows PowerShell commands to restore and backup your CAs.
However, you must install your own policy module, either from a third-party or create one yourself.
Windows 2016
As with previous deployments of Windows servers, the 2016 server implements a few hotfixes to improve certificate management, making it easier to check the status of multiple certificates at a time. Other Improvements include increased support for TPM key attestation for smart cards. Devices not on the domain can use NDES to get certificates for TPM attestation.
Windows 2019
Windows Server 2019 is based on a hybrid approach for data movement, which was lacking in the 2016 version. This means that the cloud solution can work simultaneously with the on-premise version. While Windows Server 2016 installation was simple and used AD for data backup, the 2019 version uses AI and the IoT to synchronize and backup data in a more secure way.
Root vs Intermediate CAs
In a PKI, all certificates must be issued by a valid CA. The process for issuing a certificate begins when the client generates the cryptographic keys using their credentials. In this way, the CA takes this information and generates a certificate, where the cryptographic public key and the user’s profile are input.
An interesting question is how trust is established between different CAs? Trust is given precisely because root CAs exist and the identity of all entities is known by a specific agreement in the internet community. This being the case, this is the first step of trust. Then the CA’s can be divided into two categories: root CAs and intermediate CAs.
Root CAs are CAs that serve as the “root” in a chain of trust and all certificates can be traced back to it. They issue intermediate certificates so they are protected. The root CA does not issue end-user or server certificates. Instead, Intermediate CAs have their certificates issued by the root CA and are used to sign end-user and server certificates. Multiple intermediate CAs can be configured between the root CA and the end-user certificate, creating the certificate trust chain.
Managed PKI vs On-Prem PKI (AD CS)
The cyber security industry is teeming with robust PKI solutions, so it can be challenging finding the right one. Microsoft’s Active Directory Certificate Services (AD CS) allows admins to build an on-premise PKI, and it may seem like a no-brainer for Windows customers. However, on-prem PKIs are incredibly expensive, labor-intensive, and take months to set up. Microsoft enterprises have to pay for hardware and software implementation, licensing fees, infrastructure, eventual replacement and much more. Plus, on-prem PKIs require a team of professionals to manage, meaning Azure enterprises have to dedicate time and resources to either train their IT department or find new employees.
None of this is necessary with a managed PKI service, which is a fourth of the cost of on-prem PKIs because it’s all on the cloud, can be set up in a few hours, and costs a fraction of the price of on-prem PKIs. Enterprises only need one part-time PKI manager, no expensive team of experts required. SecureW2’s Managed Cloud PKI is the actual no-brainer because it’s a turn-key PKI solution that requires no forklift upgrades.
Configuring a Managed PKI for Microsoft
Building a PKI from scratch is a grueling task, so instead of that, go with SecureW2’s Managed Cloud PKI that streamlines the implementation process. Below we’ve laid out just how easy it is to deploy a PKI for your network.
Use Our Getting Started Wizard
SecureW2’s PKI services are completely turnkey because all the necessary tools for PKI implementation are set up through our Getting Started wizard. This easy-to-use wizard will set up a Root and Intermediate CA, Base and Delta CRL, RADIUS Server, Network Policies and everything else you need to use a PKI for Wi-FI.
Windows PKI and AD/Azure AD
SecureW2’s service allows admins to integrate their SAML or LDAP Identity Provider (IDP), like AD or Azure AD, in SecureW2’s Management Portal. Now the SecureW2 certificate enrollment clients will use the IDP as a Single-Sign On for certificate enrollment, ensuring only members of the organization are issued certificates.
For more information, check out our article on configuring WPA2-Enterprise with Azure AD.
Configuring RADIUS with Microsoft GPO
With SecureW2’s Dynamic CloudRADIUS, you can edit a user’s information in the IDP and update their policy settings in realtime. Instead of replacing every certificate, CloudRADIUS communicates directly with the IDP to grant the user access based on the new settings. This empowers you to easily apply your Azure AD Access Policies to your GPO managed devices.
The authentication process is secure through the whole authentication process and the user can gain access to new resources right away. Managed devices can also be equipped with certificates with ease and be authenticated by the RADIUS. SecureW2 utilizes SCEP/WSTEP gateways to push out a certificate payload with no interaction from the end user. The certificate is populated with the user’s information and GPO-based policy settings and ready for authentication to CloudRADIUS.
Not only can this be used with GPO to auto-enroll devices for certificates, it allows organizations to easily support certificate authentication with any MDM, such as Jamf, Intune, Workspace One, and more.
Windows PKI and Access Points
The PKI and the APs don’t actually talk to each other. All that needs to be done here is to create a secure SSID that authenticates via WPA2-Enterprise / 802.1x, and enter in the RADIUS’s IP address and shared secret in the SSID settings.
Configuring Windows Devices
In order to use certificate-based authentication, devices need to be enrolled for a certificate and configured for EAP-TLS 802.1x network authentication using their certificate. Neither of these tasks are simple, unless you use SecureW2’s JoinNow onboarding software.
BYODs
SecureW2’s JoinNow solution makes it easy for admins to onboard BYODs through certificate autoenrollment and Server Certificate Validation configuration. JoinNow is able to recognize any device on the market and automatically configure it for network access.
Managed Devices
SecureW2 provides Gateway APIs for admins to send out payloads to end user devices so they are enrolled for certificates and configured for 802.1X.
Instead of manually configuring every single device or leaving it up to the end user, admins are able to issue a certificate to every managed network device. Plus, SecureW2’s Management Portal gives admins increased network visibility
Managing Microsoft Certificates
After devices have been configured for 802.1X and issued a certificate, the next part is managing issued certificates. SecureW2’s Managed PKI provides admins with CRLs, Identity Lookup, and the advanced Certificate Management GUI.
CRLs allow the RADIUS server to verify active network users. The two types of CRLs are Base and Delta and the difference lies in how often they update. The Base CRL is the standard list, it’s only referred to as Base when the Delta CRL is used.
Base CRLs can take a long time to update, slowing down the authentication process. Admins can configure Delta CRLs which contain all revoked certificates since the last Base CRL update. Since Delta CRLs are much shorter, RADIUS servers can be configured to authenticate against them instead. Admins can even adjust Delta CRL update intervals in the SecureW2 Management Portal.
Identity Lookup makes it easy for admins to search for specific certificates and identify end users. Identity Lookup verifies that an end user is still active by checking if their information is in the IDP. It used to be that only LDAP providers could use Identity Lookup, but SecureW2 expanded it to include SAML providers as well.
Our easy-to-use Certificate Management GUI simplifies all certificate management functions, and is much better than the logs of back in the day. Our GUI has loads of features like automated email notifications when a certificate is about to expire, custom certificate templates, manual revocation, and much more. Having a GUI also makes it straightforward for the Help Desk because all the attributes (MAC address, common name, computer model) are easily searchable.
Cost of a Windows PKI Server
A PKI with AD CS is also one the more expensive solutions because it requires a team of trained PKI experts dedicated to PKI management and the high cost of implementation. Organizations will need to pay for hardware and software implementation, licensing fees, infrastructure, eventual replacement and much more. With an on-prem PKI, admins will end up paying more for a solution that takes months to fully implement.
None of this is necessary with a managed PKI service, which can be set up in a few hours, and costs a fraction of the price of on-prem PKIs. The workload involved with building PKIs are shifted away from the IT admins. Enterprises only need one part-time PKI manager, no expensive team of experts required.
SecureW2’s cloud-based Managed PKI is the best option because it’s a turn-key PKI solution that requires no forklift upgrades and can be enabled in less than an hour.
Configure SecureW2 to Issue Microsoft Certificates
Windows admins can easily add their CA to SecureW2’s Management Portal and start issuing certificates to users and devices.
- Log in to your SecureW2 management portal
- Click Certificate Authorities
- Go to Add Certificate Authority
- Under Local CA use the drop down menu to find Intermediate CA
- Navigate to Generate via → Certificate Signing Request
- Underneath, find Certificate Signing Request and locate your Certificate file and upload it to SecureW2
Admins can now leverage SecureW2’s certificate issuance and management features. The imported Microsoft CA signs the certificate and gives full control to SecureW2, allowing admins to provision certificates through our intuitive onboarding software.
Issuing CA-Signed Certificate to Windows Devices
Connecting your Windows device is simple and only takes a few minutes. Here’s a quick guide on configuring a certificate onto all Windows network devices.
- Connect to your WiFi.
- Open your browser to be redirected to the onboarding client → Click JoinNow.
- An application will be downloaded → Open the application.
- A pop up will appear that will bring you to your account provider website to sign-in → Click Next.
- Sign-in using your credentials.
- Your device will automatically be enrolled, issued, authenticated, and connected in just a few seconds.
Configuring Microsoft CA with Non-Windows Devices
SecureW2’s solutions allow Microsoft admins to issue certificates to every network device, BYOD (Bring Your Own Device) and MDM. BYODs are now an important part of the business landscape since almost everyone has a smart device. However, that has historically been a pain for admins to manually configure every single BYOD for network authentication. Leaving the configuration for the end user
SecureW2 has a number of ways to issue certificates to users. Bring Your Own Devices (BYODs) are becoming more widely used in the business landscape. However, it can be a chore for admins to manually set up each and every device for authentication. If left up to the end user, the device could be misconfigured and become a security risk.
Configuring Managed Devices with Microsoft CAs
MDMs can be a costly and time consuming challenge for admins to configure for certificates. Using SecureW2’s powerful Gateway APIs, administrators can push out certificates without the need of end user interaction and can guarantee 802.1X EAP-TLS configuration for all devices.
Our Management Portal also offers a robust feature set so that administrators have everything they need to revoke, manage, and troubleshoot issues that arise with certificates.
Best Practices for Windows PKI
Configure EAP-TLS Authentication
802.1X is a network protocol that authenticates users and is imperative for secure network access. What makes 802.1X so unique is that it uses a RADIUS server, which checks a user’s information to determine if they’re an active member and what they are allowed to access.
However, not all 802.1X protocols were created equal. Avoid using credential-based protocols like EAP-TTLS/PAP or PEAP-MSCHAPv2, because both can be exploited by cyber attacks. Besides, credentials just aren’t a secure form of authentication because they are shared often or stolen. In fact, most cyber attacks occur with stolen credentials.
The best PKI security practice is authenticating users with certificate-based EAP-TLS authentication. Admins can leverage certificates to authenticate users instead of a password. EAP-TLS eliminates over-the-air credential theft, even if a certificate were to be lost, it’s virtually impenetrable and an admin can easily revoke it, rendering the certificate unable to access the network.
During EAP-TLS authentication, the RADIUS server checks the Certificate Revocation List (CRL), a list that contains every revoked certificate. Without the CRL, the RADIUS server won’t know what certificates have been revoked and could grant access to an unauthorized user.
A properly configured CRL can run itself with little admin interaction. However, it relies on the admins remembering to revoke certificates, which might not always happen, creating a security risk. Luckily, SecureW2 has improved upon RADIUS with features to address this oversight.
Configure a CloudRADIUS Server
SecureW2’s CloudRADIUS is an improved RADIUS solution because it’s powered by a Dynamic Policy Engine and strengthens 802.1X EAP-TLS authentication.
Standard EAP-TLS authentication involves storing user attributes on a certificate so the RADIUS can verify the user and apply policies right then and there. But certificates are static, meaning they can’t be modified after creation. This creates an issue because, if a user’s permissions change, an admin will have to manually revoke the certificate, create a new one, sign it with the CA, and administer it to the user.
Combine Certificates with Multi-Factor Authentication
MFA drastically improves network security because it requires more than one form of identity for authentication. The three factors of MFA are: something you know, something you have, and something you are.
But just like 802.1X, the level of security depends on how networks implement MFA. Organizations that use credentials as one of the factors will still suffer from the security gaps brought on by credential-based authentication.
The best security practice is to use digital certificates as a form of identification. Certificates can be locked onto network devices, automatically connecting devices to the network for the life of the certificate.
Use Enterprise CAs Instead of Standalone CAs
Since they’re not required to be on the domain, standalone CAs can be locked in a secure room and offline for long periods of time, signing on again to issue new certificates.
The offline CA method is noted for its security, but is becoming outdated with the adoption of cloud-based services. Online Enterprise CAs can offer far more advantages and match the security of offline CAs. The key is configuring your network to implement network security policies, which Standalones are incapable of handling.
Standalone CAs are not capable of automating monotonous tasks such as enrollment. Neither do they offer certificate templates, meaning every certificate request must be made manually and approved by a CA manager, which is time consuming.
Enterprise CAs are better suited for certificate environments because they support certificate templates and can automate certain tasks like enrollment and certificate requests. Admins can configure templates and add them to the Enterprise CA for certificate issuance.
For the best security practice and to initiate a Zero Trust philosophy, configure your setup with SecureW2 PKI and CloudRADIUS, which come at a reasonable price.
