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

1. Arnout Boer July 30, 2012 at 12:50 am

   Thanks! This was exactly what I was looking for. 😉
2. Franko October 3, 2012 at 3:27 pm

   Fixed me! Hurray!
3. Goufaka October 4, 2012 at 2:46 pm

   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.
4. Lee January 22, 2013 at 8:38 am

   Hello,

   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.

   Lee
5. Dan February 19, 2013 at 2:12 pm

   Thank you! I wonder why it would not work with the default settings.
6. voffka February 25, 2013 at 2:42 am

   Saved my day. Thank u
7. Jude April 11, 2013 at 9:42 am

   Fixed it for me. 🙂
8. nemo January 28, 2014 at 8:48 am

   I hope Microsoft adds your solution to their knowledge base soon. Helped me very much, thanks a lot.
9. Brian February 17, 2014 at 9:05 pm

   I love you man! (puts cold compress on head)
10. Charlie June 13, 2014 at 3:07 am

    u rock!
11. inthesky September 24, 2014 at 10:36 am

    ty m8!! it actually works!
12. Bryan January 15, 2015 at 2:07 pm

    Thank you, worked perfectly
13. mikechaud February 7, 2015 at 2:09 am

    Thanks man. It works like a charm.
14. Con Wulfengast February 24, 2015 at 4:56 am

    You saved me a bunch of pain with your well written solution, thanks!!
15. Skjalg Landsem January 8, 2016 at 9:26 am

    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)
16. Ugo Chukwu October 11, 2016 at 1:25 pm

    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.
17. ArmgaSys Post authorOctober 14, 2016 at 5:48 am

    Ugo, that may be true.
    But, changing the order solves the issue quickly without having to delve into SPNs. Easy always wins!
18. Michael Wigle July 25, 2017 at 6:01 pm

    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.
19. Andy January 16, 2018 at 2:55 pm

    Thank you, thank you, thank you!
    I can’t believe this is not configured out-of-the-box. Quite incredible.
20. Adeeb Al Salihi December 25, 2018 at 11:23 am

    Thanks , issue Fixed
21. damien May 15, 2020 at 11:40 am

    I know this is really old – but after all the comments, I really felt the need to say something….
    You all realise this advice is really bad…? You should not be changing this order….. Negotiate allows for Kerberos Authentication before trying NTLM.. Changing this order simply lowers your overall security without resolving the real issue. Think of it this way…. Imagine you have a choice of two front doors…… One has a tiny little lock on a door made of straw, and the other has a gigantic reinforced lock made of steel….. Now suppose that you were having problems with the gigantic reinforced lock………… To “fix” things, you decide to swap over to the door with the tiny little lock on a door made of straw… The problem is fixed, you can open it……. (so can anyone else!)….. Yes, you’ve solved the problem – but at what cost?

    In this example, Kerberos is the steel strong door and NTLM is the flimsy straw door. Would you build a house in your city with a straw door? Fix whatever is breaking your kerberos authenticaiton…! Maybe it’s an SPN -maybe you’re using a HTTP alias that is not defined as an SPN, maybe you need to set up delegation?
22. Glenn June 4, 2020 at 1:15 pm

    Ugo is right. NTLM has known security issues. Fix the SPN.
23. ArmgaSys Post authorJuly 5, 2020 at 5:32 pm

    Damien,

    We agree, in a kerberos world fixing the SPN is the correct solution. We also would say that in a kerberos world, this issue simply doesn’t exist as the SPN is setup by default (I.E it will just work).

    Looking back through our notes (the post is from 2012 after all), these issues occurred on NTLM domains. If your domain is an NTLM only domain, the solution is still effective and viable. Please do not take this as a statement that we recommend NTLM only domains (we do not). We do, however, understand that NTLM only domains do still exist in the wild for a variety of reasons and those domains may still encounter this issue.
24. Wieger August 9, 2020 at 2:32 pm

    dude, i just spent two days on this issue. Thank you for saving my ass! (and why did i not google this sooner).

25. Pingback: remote web access constantly asked for login over and over - infopvp