SEC_E_CERT_WRONG_USAGE (0X80090349) Fix Guide

1. The certificate's Enhanced Key Usage (EKU) doesn't match what you're trying to do

This is the most common reason you're seeing error 0X80090349. Every certificate has a set of Enhanced Key Usage (EKU) properties that say what it's allowed to do. For example, a certificate that says "Client Authentication" can't be used for "Server Authentication". Windows enforces this strictly.

You'll run into this when you're setting up a WinRM HTTPS listener, enabling RDP with certificate-based auth, or configuring IIS to use a certificate for HTTPS. The error pops up the moment Windows checks the EKU and sees a mismatch.

How to check the EKU on a certificate

1. Open certlm.msc (Certificate Manager for Local Machine). Press Win + R, type certlm.msc, hit Enter.
2. Navigate to the store holding your cert—usually Personal > Certificates.
3. Double-click the certificate you're using.
4. Go to the Details tab. Scroll down to Enhanced Key Usage. Click it. You'll see the list of purposes.

What you should see: If you're setting up a web server (IIS) or WinRM HTTPS listener, you need at least Server Authentication (1.3.6.1.5.5.7.3.1). If you're setting up client authentication (like EAP-TLS for VPN), you need Client Authentication (1.3.6.1.5.5.7.3.2). Some certs have both—that's fine.

The fix: get a cert with the right EKU

You have two options:

• Option A (recommended): Request a new certificate with the correct EKU from your internal CA (Active Directory Certificate Services) or a public CA. When you generate the request, specify the intended purpose. For a web server, pick Web Server template. For WinRM, pick a template that includes both Server Authentication and Client Authentication—WinRM actually needs both for the listener to work.
• Option B (quick test only): If you're just testing and using a self-signed cert, you can create one with the right EKU using PowerShell. Run this in an elevated prompt:

New-SelfSignedCertificate -DnsName "yourserver.domain.com" -CertStoreLocation "Cert:\LocalMachine\My" -KeyUsage KeyEncipherment, DigitalSignature -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2")

That command creates a cert with both Server Authentication and Client Authentication EKU. Replace the DNS name with your server's FQDN. After it runs, check the EKU in certlm.msc—it should show both purposes.

Note: Self-signed certs won't be trusted by clients unless you manually add them to the Trusted Root store. For production, use a CA-issued cert.

2. The certificate is in the wrong store

Even if the EKU is correct, the error will still show up if the cert isn't in the right store. Windows looks for certificates in specific stores depending on what you're doing. Put a server auth cert in the Local Machine store, not the Current User store. Services like IIS, WinRM, and RDP run under the SYSTEM account—they can't see your user's personal certs.

Where the cert should be

For services that run as SYSTEM (most Windows services):

• Personal store under Local Machine (certlm.msc)
• The private key must be marked as exportable (or at least accessible by the service account)

For user-specific tasks (like remote desktop as a specific user):

• Personal store under Current User (certmgr.msc)

How to move a cert between stores

1. Open certlm.msc. Right-click Personal > All Tasks > Import.
2. Browse to the .pfx or .cer file. If it's a .pfx, you'll need the password.
3. Check Mark this key as exportable if you might need to back it up later.
4. Finish the wizard. The cert now lives in the Local Machine Personal store.

After moving it: Verify the cert has a private key (you should see a little key icon next to it in the console). If it doesn't have a private key, services can't use it for encryption or authentication—you'll still get the same error or a different one.

3. The certificate template has a misconfigured purpose

If you're using an internal CA (like Windows Server AD CS), the problem might be baked into the certificate template itself. Some templates are locked to specific purposes—you can't override them by requesting a different type. The Web Server template, for example, only allows Server Authentication. The Client-Server Authentication template gives you both.

Here's a real scenario: I've seen admins issue a cert from the Workstation Authentication template, then try to use it for IIS. That template only has Client Authentication and Smart Card Logon EKU. It won't work for server authentication. The error code 0X80090349 is exactly what you'll get.

How to check and fix template settings

If you manage the CA:

1. On the CA server, open Certificate Templates console (run certsrv.msc, then click Certificate Templates).
2. Find the template you're using. Right-click it and choose Properties.
3. Go to the Extensions tab. Double-click Application Policies.
4. You'll see the list of allowed EKU. If the one you need isn't there, click Add. Pick Server Authentication or Client Authentication as needed.
5. Click OK all the way out. The template is now updated.
6. Existing certificates issued from this template won't be updated—they're already issued. You'll need to request a new cert from the corrected template.

If you don't manage the CA (you're just a user requesting certs), you're stuck with what the CA offers. Look for a template that matches your need. Common templates and their EKU:

Quick-reference summary table

Final word: The error 0X80090349 is Windows being strict about what a cert is allowed to do. That's a good thing—it prevents a cert from being used in ways it wasn't intended. But when you hit it, work through these three checks in order. Nine times out of ten, it's the EKU mismatch. Don't waste time reinstalling services or restarting servers until you've verified the cert's purpose matches what you're asking it to do.