Want to learn the best practice for configuring Chromebooks with 802.1X authentication?

Sign up for a Webinar!

High Level Comparison Of User Certificate vs. Device Certificate

Key Points
  • User certificates enlist the resources that a user can access on the network. Device certificates specify the permissions that the devices have on a network.
  • A digital certificate contains information such as Subject, DNS, Issuer, Validity, Key Size, Signature Algorithm, Serial Number, SAN, Policies, DACL, etc. User and device certificates are mainly found in Windows and macOS.
  • Device certificates are safe as they prevent nondomain users from getting them. You can modify GPO to prevent new devices from accessing the domain. A certificate cannot be issued to a non-domain user.
  • SecureW2’ PKI lets you automatically issue user/device certificates to managed and unmanaged devices in your organization through SCEP without requiring end-user interaction, enabling zero-touch security.

The popularity of digital certificates has been soaring day by day with the advancement of cloud technology. It has already replaced the traditional usage of credential-based protection in various IT domains, which is justified given its high level of cryptographic security. The exciting thing about certificates is that they not only eliminate the vulnerability of passwords but can also be tailored to suit the needs of any organization.

One of the main customizations a digital certificate provides is based on the user store and device store in some operating systems like Windows and macOS. These customizations exist because it’s important to distinguish between individual users and devices, especially when it comes to Zero Trust.

This blog will address how a user certificate varies from a device certificate and the role an operating system plays in determining that. Click here to see how smooth it was for our customers to switch from passwords to certificates.

Importance of Digital Certificates

Today the importance of digital certificates is not only acknowledged by network admins of large corporations but also by new startups and mid-level enterprises. X.509 certificates are a widely used digital certificate format based on asymmetric encryption. It uses public-private key encryption for communication over the air, adding an extra degree of cryptographic protection.

Certificate-based authentication is considered the most secure due to its encrypted EAP tunnel among various authentication protocols. It eliminates the need for credentials and provides a secure way of authentication, especially when network infrastructure is migrating to the cloud.

It also prevents users from connecting to and authenticating to the wrong RADIUS servers by equipping your RADIUS server with a certificate of its own in a process called server certificate validation.

Structure of X.509 Digital Certificates

Each X.509 certificate has several attributes based on its certificate template. The common X.509 certificate fields include the following:

  • Subject
  • DNS
  • Issuer
  • Validity
  • Key Size
  • Signature Algorithm
  • Serial Number
  • SAN
  • Policies
  • DACL

It is tough to customize your certificate template based on users and device attributes by an average PKI. SecureW2’s PKI allows you to make custom certificate templates based on your specific needs. This matters because you can put a user-based value on a device certificate and a device-based value on a user certificate, which is a huge demand for many network admins.

Comparison of User and Device Certificate

The concept of a User and Device certificate would only make sense for the Windows and macOS operating systems, and it’s mostly going to be device certificates for the other operating systems. In general terminology, a device certificate is also addressed as a machine or computer certificate.

The miscellaneous data that goes into the certificate (like user or device attributes) decides whether it’s a user or device certificate. It can vary functionality-wise based on the operating system. A device certificate is usually present in the Local Computer store while the User certificate resides in the User’s certificate store.

User certificates specify which resources a given user can have access to. They are sometimes used on devices that several users share. When different users log in, their profiles and certificate are automatically loaded, granting them access to their required information. This is critical if different users of the same device need access to different resources.

Device certificates identify specific devices and their permissions. They are typically used when a device has only a single user (hence no need for numerous user certificates) or when an IoT device has no users.

Most organizations would use machine certificates to ensure that the device is connected to the internet prior to an individual signing in. However, some organizations will do both user and machine certificates when multiple users are on a device to ensure the correct user certificate and access are applied once a user logs in after the device is authenticated.

User and Device Certificates in Managed Windows Environments

Machine certificates are necessary for managed Windows environments because they are critical for signing into the device, as devices need network access to validate the user’s login credentials to the Active directory. So basically, in Windows, the configuration would auto-switch from machine certificate to user certificate to monitor the network activities easily.

But the same does not hold for the macOS operating system, which has two different certificate stores, termed system keychain and user keychain, as separate entities.

Also, suppose you plan to use AD CS to generate user and device certificates internally. In that case, the designated certification authorities (CAs) generate the certificates by using the templates created by the admins. Then AD CS uses the Group Policy to deploy certificates to the devices of domain members. Then the device or user certificates are automatically deployed to domain members when their device starts or the users log in.

Requirements of User and Device Certificates

The Subject name field contains a value which is mostly the name of the user/device to which the CA issues the certificate. If you issue a certificate with a blank subject name, that certificate is considered invalid and cannot be used for authentication.

The template has a field called Application Policies extensions, also known as Enhanced Key Usage (EKU) extensions, where the user or computer certificate is configured with Client Authentication purposes. Client Authentication’s object identifier is 1.3.6.1.5.5.7.3.2. Application Policies extensions are included by default in the User and Workstation Authentication certificate formats.

If the Subject Alternative Name (SubjectAltName) extension is used for user certificates, it contains the User Principal Name (UPN). Here the UPN is configured with the User certificate template by default.

On the other hand, device certificates have the computer’s Fully Qualified Domain Name (FQDN) in the SubjectAltName field. But you must configure the Workstation Authentication Certificate template for this requirement.

Are User/Device Certificates Secure?

Although the user certificates are kept only in those folders that the user has access to, the CNG Key Isolation (a shared process that operates as a LocalSystem and is hosted in the LSA process) service encrypts them by storing cryptographic information securely. It prohibits the keys from being exported till the user receives administrator access. You can export both the device and user key only after the user gets admin access.

You need an administrator to read the local computer store, but that does not contribute to the security of the certificates since it can neither export the private keys of the device nor the user certificate. You must be present on a domain device to get a User certificate issued to you, signaling it’s a company asset.

You can also modify the Group Policy Object (GPO) to prevent normal users from attaching new devices to the domain. It can prevent a non-domain user from obtaining a certificate if you strictly allow user certificates from a device already part of the same domain. After issuing the certificate, its export is prevented to non-domain devices for further use.

Securew2: The Best Certificate-Driven Security

It is now a well-proven fact that the credentials are susceptible to numerous cyber threats, and digital certificates have successfully eliminated most of them. Certificates can help secure your network, but only if you have the necessary deployment and administration tools in place.

You can utilize the top perks of these certificates only if it is backed by a proficient Certificate Authority (CA) that can manage their entire lifecycle easily. We at SecureW2 are committed to enriching your entire onboarding process with digital certificates smoother and super easy. Our PKI also provides numerous customization such as customized user and device certificates based on the needs of our customers.

We even provide many advanced features such as auto revocation in collaboration with leading MDMs such as Jamf and Intune. Our SCEP gateway makes it easy to push certificates to all managed devices without end-user interaction. We have affordable options for organizations of all sizes. Click here to see our pricing.

Learn about this author

Vivek Raj

Vivek is a Digital Content Specialist from the garden city of Bangalore. A graduate in Electrical Engineering, he has always pursued writing as his passion. Besides writing, you can find him watching (or even playing) soccer, tennis, or his favorite cricket.

High Level Comparison Of User Certificate vs. Device Certificate