CertSrv Continuously asks for Username & Password (AKA CertSrv 401 Unauthorized)

At ArmgaSys, we consume SSL certificates at a ferocious rate.  Lync, Exchange, OWA, and UM all require SSL certificates to secure the multitude of communication channels. 

While much debate rages around “Should I purchase a public certificate which will only be used on internal servers”, the reality in the field is many companies choose to leverage Active Directory Certificate Services.  This is done for one very good reason:  Internally generated (and trusted) certificates are free.

One of the issues we run into when requesting new certificates from ADCS is the dreaded 401 Unauthorized issue with Certsrv.

The Scenario

  1. Type the URL for your Certificate Server
    http://[domain server]/certsrv
  2. You are prompted for administrator credentials
  3. You enter said credentials
  4. You are again prompted for administrator credentials
  5. You enter said credentials
  6. You are presented with a 401 Unauthorized error message
  7. You bang your head against your desk in frustration

Root Cause

The IIS server is not negotiating your credentials correctly.


  1. Logon to the server hosting the Active Directory Certificate Services
  2. Launch Internet Information Services (IIS) Manager
  3. Drill down and click on the the CertServ application
    (Usually Server –> Sites –> Default Web Site –> CertSrv)
  4. Click and open the Authentication icon in the home view
  5. Click once on Windows Authentication to highlight the entry
  6. Select Providers from the action pain (located a the right of the IIS Manager)
  7. Move the NTLM provider to the top of the list.  It *must* be the first enabled provider
  8. Restart IIS using IISRESET at the command prompt

Happy Certificate Issuing!

20 thoughts on “CertSrv Continuously asks for Username & Password (AKA CertSrv 401 Unauthorized)

  1. Goufaka

    And this is why I value the tech community. It would have taken me a long time to track this down. Much appreciation for posting this simple yet important solution.

  2. Lee


    Thanks for this helpful information on IIS.

    I am curious why NTLM needs to be listed first(above Negotiate).

    If Negotiate is first I thought it would try both and if Kerberos failed it would use NTLM. Is this not the case?

    Thanks for your help.


  3. nemo

    I hope Microsoft adds your solution to their knowledge base soon. Helped me very much, thanks a lot.

  4. Skjalg Landsem

    This solved the issue for me too! 🙂
    NB: in another domain I administer I did not have any problems logging in to https://localhost/certsrv – and that CA server also had the same “Negotiation” before “NTLM”. So on that server “NTLM” did not need to be first in the list. Same server OS and patch level (2008R2 w/Enterprise CA)

  5. Ugo Chukwu

    You should not have to change the order. The underlying issue should be resolved without changing the order as a work around. The underlying issue is that SPN for the service is missing.

  6. Michael Wigle

    Thank-you so much! I had found this solution on other sites but they didn’t include step 8! I was restarting the web site instead of IIS, which didn’t take the change.

  7. Andy

    Thank you, thank you, thank you!
    I can’t believe this is not configured out-of-the-box. Quite incredible.

Leave a Reply

Your email address will not be published. Required fields are marked *