Microsoft Exchange Server 2010/2013/2016/2019 – Unable to connect to OWA/ECP “protectionCertificates.Length<1"

Microsoft have done it again, with another security update, they’ve broken a lot of environments, I wish there was a better communication method than finding a small footnote on a blog post that a patch was going to potentially break environments. Many organisations have automated patch workflows that end up catching people out when this stuff happens, it’s a good reason to use technologies such as Veeam’s DataLabs to test patches before production, but that’s a story for another time…

Ok, what did Microsoft break this time?

Two things, and you’re likely here because either:

  1. You can’t access OWA/ECP
  2. You’re being bounced back to the main OWA page when trying to sign in and you’ve got a load balancer.

BUT wait there’s more! Microsoft have quietly updated the Microsoft Exchange schema in this security update, be sure to update your schema AFTER installed the July 2021 SU (Security Update).

Problem One, “protectionCertificates.Length<1”:

The full error code is “HMACProvider.GetCertificates:protectionCertificates.Length<1”

Good news: This one isn’t so bad to fix, Bad news: You’ve got to pay more attention to your environment from now on.

This error appears to be triggered when the OAuth certificate (Microsoft Exchange Server Auth Certificate) has expired, Microsoft have now published an article outlining exactly this, so I’d now expect OWA/ECP to stop working whenever your OAuth certificate has expired.

To solve this problem carry out the following:

  1. Open Exchange Management Shell as Administrator
  2. Run the following command. (Replace with your SMTP domain)
New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName ""

3. Take note of your thumbprint, you’ll need it for the next command. Now run the rest of the commands.

Set-AuthConfig -NewCertificateThumbprint <ThumbprintFromStep1> -NewCertificateEffectiveDate (Get-Date)
Set-AuthConfig -PublishCertificate
Set-AuthConfig -ClearPreviousCertificate
Restart-Service MSExchangeServiceHost
Restart-WebAppPool MSExchangeOWAAppPool
Restart-WebAppPool MSExchangeECPAppPool

4. If you have multiple Exchange servers, you’ll need to run the following commands on each of them, but wait for the new Exchange Auth Certificate to be replicated to them first.

Restart-Service MSExchangeServiceHost
Restart-WebAppPool MSExchangeOWAAppPool
Restart-WebAppPool MSExchangeECPAppPool

5. Wait, this can take a few hours to replicate across (more than the one hour Microsoft state), but then everything will start working again. If you wish to confirm each server is aware of the new Auth configuration you can run “Get-AuthConfig” and validate the Thumbprint and effective date match your new certificate and the time you executed the first “Set-AuthConfig” command respectively. If you have a Hybrid Exchange environment you need to rerun the “Hybrid Configuration Wizard” again to update these changes to Azure Active Directory.

You may find that this isn’t enough, whilst Microsoft don’t reference it within their support document, I’ve also found expired Backend certificates causing this problem too, though based on the time delays mentioned above this could be coincidental. If your backend certificates have expired, this is also quite easy to replace, gather the Thumbprint of the certificate currently being used by the backend and then run the following command:

Get-ExchangeCertificate -thumbprint “Thumbprint” | New-ExchangeCertificate

Once this has been done, change the certificate binding on your Exchange Server by opening IIS, browsing to the “Exchange Back End “site, selecting “Bindings” and editing the HTTPS binding to use the new certificate. It will have the same name as the old certificate so ensure you click “View” to see the properties of your certificate, making sure the certificate has the new expiry.

Problem Two, Cannot log into OWA or ECP, login loop (Using load balancer)

If you’ve got a load balancer and you’re getting a sign-in loop after installing the SU, I also have good news for you, you’re doing things right in that you’re taking a phased rollout to minimize downtime (or so I hope!). But the bad news is that the July 2021 SU for Exchange 2013/2016/2019 does not support being partially deployed, once you’ve started the rollout you need to ensure you don’t maintain a “mixed pool” of patched and unpatched servers to resolve this issue.

Bonus Points: Update your AD Schema

Remember from earlier in the article I highlighted that the AD schema has changed, if you’re using Exchange Server 2013, you’re likely not used to updating your schema anymore as there aren’t any Cumulative Updates for Exchange that normally necessitated this. However if you didn’t update your schema for Exchange 2016/2019 during the June CU updates this applies to you too! To update your schema, open an administrative PowerShell, set yourself to the directory (cd command) of the Exchange Setup.exe. For example with Exchange Server 2013 the default is “C:\Program Files\Microsoft\Exchange Server\V15\Bin\”. Then run the following command.

Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

IMPORTANT: Remember when updating your schema, you require Schema Admin or Enterprise Admin privileges, Domain Admin isn’t sufficient.

Error Codes (To help others on their search to this article)

MSExchange Front End HTTP Proxy – Event ID 1003

“[Owa] An internal server error occurred. The unhandled exception was: Microsoft.Exchange.Diagnostics.ExAssertException: ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1”

ASP.NET 4.0.30319.0 – Event ID 1309

“Event code: 3005
Event message: An unhandled exception has occurred.”

19 responses to “Microsoft Exchange Server 2010/2013/2016/2019 – Unable to connect to OWA/ECP “protectionCertificates.Length<1"”

  1. Important note for future readers: the Set-AuthConfig -NewCertificateThumbprint “taking a few hours to work” depends on your timezone. So if you’re in NZ, it takes 12 hours to work because the command assumes you’re giving it UTC Effective Date. To get around this you can either change your server’s timezone to UTC temporarily or adjust the command.


    1. Hi Brenden, I’ve heard others say this too but as I’m not in such a time zone I haven’t experienced this first hand, but yes, if you run the Get-AuthConfig you can see the effective date for this as well to validate if you have a time delay for this to take effect. As it will give you two datetime outputs, one of them in UTC and one that should be localised. One way around this would be instead of using Get-Date directly in the command you could create a variable called $date by running “$date = Get-Date” and then manipulate the hours relative to your time zone by then running $date = $date.AddHours(-NumOfHours) and then using $date as your variable in the Set-AuthConfig command instead of Get-Date directly.


      1. Unfortunately, this method also doesn’t work, since we receive this:
        “The new certificate effective date is invalid. The effective date must be greater than the current time.”


      2. Hi Aerocom, the suggestion I made is for people on -UTC time zones, you can use a + instead of a minus to implement this on time zones ahead relative to UTC. Hope this helps!

        Liked by 1 person

  2. Avatar

    When executing New-ExchangeCertificate should I overwrite the existing default SMTP certificate when asked by server?


    1. Hi, it depends if the certificate you’re using for your SMTP is expiring/expired, otherwise you don’t need to use it for SMTP.


      1. Avatar

        OK – i’ve checked and it is still valid.


  3. The solution worked for me but now every time I go anywhere in EMC i get an pop-up error message:
    Your request couldn’t be completed. Please try again in a few minutes.

    I have to click numerous times for it to go away and it starts all over once I change a tab or a menu item. I see the following MSExchange Control Panel even id 5 error in Application log of the server:
    Current user: ‘’
    Web service call ‘’ failed with the following error:
    System.ServiceModel.Dispatcher.NetDispatcherFaultException: The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter ECP:identity. The InnerException message was ‘There was an error deserializing the object of type Microsoft.Exchange.Management.ControlPanel.Identity. End element ‘RawIdentity’ from namespace ” expected. Found element ‘target’ from namespace ”.’. Please see InnerException for more details. —> System.Runtime.Serialization.SerializationException: There was an error deserializing the object of type Microsoft.Exchange.Management.ControlPanel.Identity. End element ‘RawIdentity’ from namespace ” expected. Found element ‘target’ from namespace ”. —> System.Xml.XmlException: End element ‘RawIdentity’ from namespace ” expected. Found element ‘target’ from namespace ”.


    1. How long did you wait after swapping all of your expired certificates?


      1. Did the swap, went to sleep. In the morning checked and that is how it is working now…


      2. Without seeing it for myself I’d suggest you check all of your SANs are valid on the relevant certificates and restart the Exchange services. If you haven’t closed your web browser between certificate swaps you could have a stale certificate cached there too.


  4. Good point. I tried with Incognito, but that did not help. Tried from another VM and error is not present. So it does seem to be related to the machine I’m openning the EMC from. Will troubleshoot more.
    Thank you for your suggestions!


    1. No worries, incognito I’ve found doesn’t get a fresh cert if the non-incognito has already fetched it, it’s not quite the same as freshly browsing, give your machine a reboot (assuming you’re not accessing from Exchange directly) and try again


  5. Ouch
    And now how do you put a let’s encrypt cert for wildcard domain ?



    1. Hi,

      That’s outside of what I’m talking about here. At a high level, use whatever preferred tool of choice to generate your wildcard certificate. Then import your cert via either EAC or EMS, Microsoft have that part well documented:


  6. Stanthewizzard Avatar

    Inside a little 🙂

    I followed the workaround. It Works.
    When logging to OWA. Cert is unknown (self signed).
    Same for internal or external access.

    I have a pfx made from let’s encrypt
    I import the pfx with this
    certutil -delstore My
    certutil -f -p “” -importpfx c:\sdskhcom\

    and then

    thumbprint is the one from pfx

    Set-AuthConfig -NewCertificateThumbprint thumbprint -NewCertificateEffectiveDate $Time.ToUniversalTime()
    Set-AuthConfig -PublishCertificate
    Set-AuthConfig -ClearPreviousCertificate
    Restart-Service MSExchangeServiceHost
    Restart-WebAppPool MSExchangeOWAAppPool
    Restart-WebAppPool MSExchangeECPAppPool

    After that … owa or ecp > loop login

    BUT I remade the pfx with CSP “Microsoft Enhanced RSA and AES Cryptographic Provider”

    cd /root/ && openssl pkcs12 -export -out exchange.pfx -inkey NAME.key -in NAME.cer -name “le2.NAME” -passout pass:asKA3822 -CSP “Microsoft Enhanced RSA and AES Cryptographic Provider” -certpbe PBE-SHA1-3DES -keypbe PBE-SHA1-3DES -macalg sha1

    before it was made like this
    cd /root/ && openssl pkcs12 -export -out NAME.pfx -inkey NAME.key -in NAME.cer -name “” -passout pass:

    and then import is different
    certutil -csp “Microsoft RSA SChannel Cryptographic Provider” -f -p “PASS” -importpfx c:\name\exchange.pfx

    Now Set-AuthConfig is working
    no more loop login


    1. Thanks for sharing, though as always I’d advise people to read the code and understand what they’re doing before blindly executing code on the internet! Glad you got your SSL generation issues sorted.


  7. Hello.
    Recently on our Exchange 2019 CU12 server, I updated an Auth Certificate, installed a new certificate, and verified that I can access ECP and log in to OWA with the IP addresses of two Exchange servers, and I am using the new certificate. But SLB is used in the environment, and SLB VIP is used to log in and access, when I go to ECP URL to log in, it redirects to OWA URL:


    The following IIS recycling commands have been executed, and it does not work.

    [PS] C:>Restart-WebAppPool “MSExchangeOWAAppPool”

    [PS] C:>Restart-WebAppPool “MSExchangeECPAppPool”

    The strange thing is that after waiting for 8 hours, the SLB VIP access is normal. I think the CU12 version still does not solve the problem of UTC time zone, although there is no phenomenon of “ASSERT: HMACProvider.GetCertificates:protectionCertificates.Length<1" in the previous version .

    Admin please help, thanks


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: