LS Audio/Video Authentication Server Error 19008 – Private Key not found

After happily running for several years, one of the Skype for Business edge servers for one implementation decided it was not going to start its Audio/Video Authentication and Audio/Video Edge service!

Looking at the event viewer, the following two Event IDs were raised: 19008 and 19005. Specifically: 19008: Private key for server certificate not found by the LS A/V Authentication service or the service does not have sufficient permissions to access the certificate.

After verifying the private key permissions are set correctly (NETWORK SERVICE: Read, etc) in the Certificate MMC snap-in, I checked to see what the certs looked like in PowerShell

PS Cert:\LocalMachine\My\> dir .\ 5E670E493E5EBAACC5B26E219ACA8A629F9485D4 | fl 

HasPrivateKey  : True
PrivateKey     :
PublicKey      : System.Security.Cryptography.X509Certificates.PublicKey

Notice that there is no PrivateKey provider defined here, which means the cert broke somehow! Strange, as in this environment there were two Skype for Business edge servers, one worked perfectly, the other did not.

Anyways, the fix was to tear the certs apart, and put them back together as shown in this Merge certificate public and private key with OpenSSL TechNet article.

Specifically

    1. I got the OpenSSL binaries from: https://indy.fulgan.com/SSL
    2. I extracted the keys using the following commands:
      openssl pkcs12 -in egdev1.pfx -nocerts -out private_key.pem -nodes
      openssl pkcs12 -in egdev1.pfx -nokeys -out public_key.crt
    3. I merged the keys back together using the following command:
      openssl pkcs12 -export -in public_key.crt -inkey private_key.pem -out lync_edge_merged.pfx

After certificate import, and applying it to the services, I checked to see what the certs looked like in PowerShell

PS Cert:\LocalMachine\My\> dir .\ 5E670E493E5EBAACC5B26E219ACA8A629F9485D4 | fl 

HasPrivateKey  : True
PrivateKey     : System.Security.Cryptography.RSACryptoServiceProvider
PublicKey      : System.Security.Cryptography.X509Certificates.PublicKey

Notice that there is now a PrivateKey provider defined here, and the two Audio/Video Authentication and Audio/Video Edge services started up just perfectly!

Author: Luke Edson

Luke has extensive experience in a wide variety of systems, focusing on Microsoft technologies, Communication with Exchange and Skype for Business (Lync & LCS), Data Center Virtualization, Orchestration and Automation, System Center Management, Networking, and Security.

7 thoughts on “LS Audio/Video Authentication Server Error 19008 – Private Key not found”

  1. Fantastic!
    I had the exact same problem. Some articles suggested assigning the internal certificate to the AV service but that just didn’t feel right since we’ve had the public cert assigned for four years without a problem. The problem occurred when updating to a new public cert. This article solved it. Thanks!

    Like

  2. I don’t normally comment on these, but I want to leave some breadcrumbs in Google for people who may run in to similar issues that I have. We have spent the last few weeks going through a round of 3 year cert expirations and replacements. Every public cert we get from Digicert (CSR generated in Windows, cert issued from Digicert) has come with this EXACT situation: Private Key provider blank when looking at the cert in powershell. I found this page because we had this exact issue with Skype when we rolled those certs. However, we also had issues with other MS platforms as well:

    Dynamics / CRM: After installing a new cert where the Private Key was blank instead of showing the provider, CRM would not allow people to log in. The metadata file for integration with ADFS existed and was accessible, but the file was significantly shorter than it should have been and included errors indicating that it could not correctly generate the metadata.

    Exchange 2013 – OWA and ECP “login loop”: Using a cert with this issue on Exchange results in strange behavior as well. Email sends and arrives without issue. OWA and ECP pages will load and present the cert as valid for TLS. If you are using Basic Auth or Windows Auth (get-ecpvirtualdirectory | fl *, get-owavirtualdirectory | fl *), both services will work without fail. However, if you are using Forms Auth for OWA and ECP then logins will fail. The page will load normally but when you give valid creds it will dump you back to the login page immediately. There are several docs out there on Exchange OWA/ECP “login loops”, but I did not find any that addressed this issue.

    All of these issues were fixed by the OpenSSL steps Luke has outlined here.

    What I am unsure of is why I have recently gotten so many certs from Digicert that display this issue. I know there was a recent RFC that made changes to the issuance of publicly trusted certs (underscores are no longer allowed, for example) but I have not sat down and read all the content of the RFC to see if this behavior change was a part of it. Perhaps it is something about CSRs coming from Server 2016.

    Anywho, I hope this helps someone the way it helped us. MS products seem to depend on seeing the PrivateKey provider for some strange, specific uses.

    Thanks!

    Like

Leave a Reply

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

WordPress.com Logo

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

Google photo

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

Twitter picture

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

Facebook photo

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

Connecting to %s