Loading...Understand how Enhanced EKU defines and restricts what an SSL certificate can be used for — and why that matters for your web security.
When dealing with SSL/TLS certificates, you may come across the term Enhanced or Extended Key Usage (EKU) in certificate specifications or validation errors. But what exactly does EKU mean, and why is it important?
Let’s break it down in simple terms, especially for developers, sysadmins, and IT security professionals managing web servers, email security, code signing, or client authentication.
What Is Extended Key Usage (EKU)?
Extended Key Usage (EKU) sometimes called Enhanced Key Usage — is a part of an SSL certificate that tells computers exactly what that certificate is allowed to do. Think of it as a permission list.
Every SSL certificate has a public key inside it, and that key can do different things — like secure a website, confirm someone’s identity, or sign a piece of software. The EKU field spells out which of those tasks the certificate is trusted to perform.
Here are two common examples:
- Server Authentication — This means the certificate is allowed to secure websites using HTTPS. It’s one of the most common uses.
- Client Authentication — This is used when someone (like a user or device) needs to prove who they are to a system.
Without the correct EKU settings, the certificate might not work for what you intended. Your browser, operating system, or server will double-check this field before trusting the certificate.
Other uses for EKU include:
- Email protection (S/MIME)
- Code signing
- Document signing
- Time stamping
What Makes It “Enhanced” or “Extended”?
First off, you may be wondering: is it enhanced or extended? The technically correct term is Extended Key Usage. However, Enhanced Key Usage is also very commonly used, especially in Windows environments (due in part to Microsoft using both terms in their documentation). You can consider them interchangeable terms.
It’s called extended key usage, because it extends the “Key Usage” field. The “Key Usage” field specifies very general uses, such as encipherment, digital signature, etc, The Extended Key Usage extends that to more specific uses such as Server Authentication or Code Signing.
Why EKU Matters for SSL Certificates
When you install an SSL certificate on your web server (Apache, Nginx, IIS, etc.), it must include the correct EKU OID for server authentication:
- TLS Web Server Authentication → OID: 1.3.6.1.5.5.7.3.1
If this OID is missing, major browsers and operating systems may reject the certificate, causing SSL errors like:
- NET::ERR_CERT_INVALID
- SSL_ERROR_BAD_CERT_ALERT
- Remote Desktop connection errors in Windows
Examples of Common EKU Values
| Purpose | EKU OID |
| TLS Web Server Auth | 1.3.6.1.5.5.7.3.1 |
| TLS Client Auth | 1.3.6.1.5.5.7.3.2 |
| Code Signing | 1.3.6.1.5.5.7.3.3 |
| Email Protection (S/MIME) | 1.3.6.1.5.5.7.3.4 |
| Time Stamping | 1.3.6.1.5.5.7.3.8 |
How to Check EKU in a Certificate
Here’s an example of how to check the Extended Key Usage (EKU) value in a certificate using OpenSSL:
Using OpenSSL (for .pem, .crt, or .cer files):
Run this command in your terminal:
Look for a section like this in the output:
TLS Web Server Authentication, TLS Web Client Authentication
This tells you what the certificate is allowed to do.
Using Windows Certificate Viewer:
- Double-click the certificate file (.cer, .pfx, or from the Windows store).
- Go to the Details tab.
- Find the Enhanced Key Usage field.
- It will list allowed usages like “Server Authentication” or “Client Authentication”.
What Happens If EKU Is Missing or Incorrect?
If your SSL certificate has the wrong EKU or is missing the required OID, it may:
- Fail to establish secure connections.
- Trigger browser warnings or errors.
- Be unusable for certain purposes (e.g. you can’t use a client-only certificate for a server).
Important: Multi-purpose certificates (like S/MIME + SSL) must contain all relevant EKU OIDs.
How to Ensure Your Certificate Has the Correct EKU
- Buy from a trusted CA: Most public CAs automatically assign the proper EKU based on the certificate type (DV, OV, EV SSL, code signing, etc.).
- Avoid repurposing certificates: Don’t use a web server certificate for code signing or vice versa — they are not interchangeable.
- Double-check during CSR and issuance: Some internal tools or misconfigured CAs can produce certificates with incomplete or incorrect EKU.
Summary
- EKU (Extended Key Usage) defines the allowed functions of an SSL certificate.
- “Enhanced EKU” usually refers to strict enforcement of EKU by systems like Windows.
- For SSL/TLS, the key EKU OID is 1.3.6.1.5.5.7.3.1 (TLS Web Server Authentication).
- Certificates must include the correct EKUs to avoid trust errors.
If you’re managing certificates across different systems (web, email, RDP, etc.), always make sure the EKU values match the intended usage.
Upcoming Changes to EKU Requirements
Several major certificate authorities and browser vendors are changing how EKU values are handled to improve clarity and security.
Starting September 2025 some Certificate Authorities will stop including the clientAuth EKU in any newly issued TLS server certificates. This means that their certificates will be dedicated to server authentication only, helping to prevent potential misuse or confusion. This change is guided by the Google Chrome Root Program Policy.
On the beginning of June 15, 2026, any TLS server certificate that chains to a root in the Chrome Root Store must include only the serverAuth EKU. Certificates containing both serverAuth and clientAuth will be rejected for HTTPS in Chrome.
This means that organizations currently using a single certificate for both server and client authentication will need to switch to separate certificates for each use case. It’s important to plan ahead and ensure any new certificates issued for web servers follow this new requirement to avoid browser trust errors after the policy goes into effect.
Need a client authentication certificate? We recommend this one:
DigiCert Secure Email Certificate
