Introduction
DirectAccess is an IPv6 only solution, at least from the perspective of the client. When the DirectAccess client is remote, it communicates with the DirectAccess server using IPv6 exclusively. IPv6 transition technologies are used to enable this connectivity when the DirectAccess server and/or client are on the pubic IPv4 Internet.
IP-HTTPS
One of the IPv6 transition technologies used by DirectAccess is IP-HTTPS. With IP-HTTPS, IPv6 traffic is encapsulated in HTTP and delivered to the DirectAccess server using IPv4. IP-HTTPS is used exclusively when the DirectAccess server is located behind an edge firewall performing network address translation.
SSL Certificate
To support IP-HTTPS, an SSL certificate is installed on each DirectAccess server. The SSL certificate is commonly issued by a public certification authority, but it can also be issued by an internal PKI. The SSL certificate used for IP-HTTPS can and does expire, and when it does it will prevent any DirectAccess connection from being established using this transition technology.
Troubleshooting
When troubleshooting DirectAccess connectivity via IP-HTTPS, the first thing the administrator will notice is that the media state for the DirectAccess client’s IP-HTTPS tunnel adapter interface is shown as disconnected.
In addition, the Get-NetIPHttpsState PowerShell command returns an error code 0x800b0101 indicating Failed to connect to the IP-HTTPS server; waiting to reconnect.
Err.exe translates this error to CERT_E_EXPIRED, indicating that the SSL certificate is no longer valid.
Viewing the IP-HTTPS SSL certificate is not possible using a web browser. Instead, use Nmap and the ssl-cert script to view the certificate.
nmap.exe -n -Pn -p443 [FQDN] –script ssl-cert
In the Operations Status window of the Remote Access Management console on the DirectAccess server, the IP-HTTPS status is listed as Critical. Details show IP-HTTPS not working properly, with an error stating the IP-HTTPS certificate is not valid, and clearly indicating that the certificate is expired.
The IP-HTTPS status can also be viewed at the command line by issuing the following command in an elevated PowerShell command window.
Get-RemoteAccessHealth | Where-Object Component -eq IP-Https | Format-List
Updating the Certificate
Simply renewing the SSL certificate is not sufficient to restore IP-HTTPS connectivity for remote DirectAccess clients. The DirectAccess configuration must also be updated to use the new certificate. In the Remote Access Management console, highlight DirectAccess and VPN under Configuration and then click Edit on Step 2 (for load-balanced or multisite DirectAccess deployments, first highlight the individual server and then click Configure Server Settings). Click Network Adapters, click Browse, and then select the new SSL certificate.
Click Ok, Next, and then Finish twice and Apply. Repeat these steps for each server in the load-balanced cluster, and for all servers in all entry points in the enterprise.
Alternatively, the IP-HTTPS certificate can be updated in the DirectAccess configuration by opening an elevated PowerShell command window and entering the following commands.
$cert = Get-ChildItem -Path cert:\localmachine\my | Where-Object Thumbprint -eq [cert_thumbprint]
Set-RemoteAccess -SslCertificate $cert -Verbose
For example…
$cert = Get-ChildItem -Path cert:\localmachine\my | Where-Object Thumbprint -eq 2BFD1BC5805EBBF8ACB584DA025AD75B341A8B33
Set-RemoteAccess -SslCertificate $cert -Verbose
Important Note: Be sure to execute these commands on each DirectAccess server in the load-balanced cluster, and for all servers in all entry points in the enterprise.
Self-Signed Certificates
When DirectAccess is deployed using the Getting Started Wizard (GSW), also known as a “simplified deployment“, a self-signed certificate is used for IP-HTTPS. By default, this certificate expires 5 years after it is created. The expiration of a self-signed certificate presentsa unique challenge. Although the self-signed certificate can’t be renewed, it can be re-created or cloned using the New-SelfSignedCertificate PowerShell command. However, DirectAccess clients will not trust this new certificate until they receive the updated client settings via group policy. DirectAccess clients outside the network will not be able to establish IP-HTTPS connections until they receive these new policies. When they attempt to connect to the DirectAccess server without first updating group policy, the IP-HTTPS status will indicate an error code 0x800b0109 which translates to CERT_E_UNTRUSTEDROOT.
If the expired self-signed certificate is replaced with another self-signed certificate (not recommended), DirectAccess clients will have to come back to the internal network or connect remotely via client-based VPN to update group policy and receive the new DirectAccess client settings. A better alternative is to replace the expired self-signed certificate with a public SSL certificate that matches the existing public hostname. This will allow remote clients to reestablish DirectAccess connectivity without the need to udpate group policy first.
Summary
Certificate expiration must be monitored closely to ensure the highest level of availability for the DirectAccess remote access solution. Certificate auto enrollment can be leveraged to ensure that IPsec certificates are automatically renewed prior to expiration. However, the IP-HTTPS certificate must be renewed manually and requires additional configuration after it has been updated.
Additional Resources
DirectAccess Computer Certificate Auto Enrollment
DirectAccess and Multi-SAN SSL Certificates for IP-HTTPS
John
/ November 15, 2016So, that should work great if using a certificate issued by a trusted CA (internal or external). I know some places have self-signed certs for DA, which are trusted by workstations via the DA GPOs assigned to them. In that case, if expired, they’ll be dead unless can get on the domain’s network for doing a GPUpdate or making them do a remote-join to the domain and sending them the necessary files. Correct? Not sure if there a more elegant method of handling self-signed cert expiration (before or after they expired), or if worth providing the feedback on the article, don’t want to detract from the good work you have done. Just thought I’d mention it for additional perspective. Thanks.
Richard M. Hicks
/ November 16, 2016Interesting point, John! You bring up a scenario that I had not considered. Using a self-signed certificate for IP-HTTPS is not recommended, but it is implemented by default when you deploy DirectAccess using the Getting Started Wizard. That is something I never do, hence the oversight here. Thank you for bringing this to my attention though! I’ll update the blog post with guidance for this scenario ASAP. Thanks! 🙂
Patric
/ January 12, 2017Thanks for the great post(s) Richard. One question regarding Certificates issued by an internal PKI: Our internal IssuingCA expires soon and has to be renewed. When renewing, we would like to take the opportunity to upgrade it fom sha-1 signatures to sha-256. When we initially set-up DA in 2015 (on Windows Server 2012R2) we have been told that it does not support sha-256, but only sha-1. Can you confirm or bust this myth? I couldn’t find any information on thios topic yet. Thanks again!
Richard M. Hicks
/ January 16, 2017That’s definitely a myth. DirectAccess absolutely works certificates signed with SHA-2. If you are migrating from SHA-1 to SHA-2, the only change required on the DirectAccess server is to select the new root certificate. If it is the same CA or common name there is nothing else required. If you are also migrating to a new PKI hierarchy, the the change will be disruptive as remote DirectAccess clients will have to come back to the office or connect via VPN to update group policy.
philready
/ August 6, 2017Hi Richard
Is it a similar fix when the IPsec cert expires? Where is the IPsec cert set?
Richard M. Hicks
/ August 12, 2017No. If the IPsec certificate expires you simply need to renew it. You don’t have to do anything specific in the DirectAccess configuration once that’s done. As long as there is at least one valid computer certificate with the Client Authentication EKU it will work. 🙂
JB
/ March 8, 2018Hi Richard,
We attempted to replace our public IPHTTPS cert recently due to the Google / Symantec falling-out.
Windows 10 Clients were unaffected after the change but Windows 7 clients using the DCA refused to connect. We had to roll back given the reliance on DA so I was unable to troubleshoot properly.
Would the new root and intermediate need to be present or will the client build the chain?
Richard M. Hicks
/ March 10, 2018Yes, the certificate chain must be complete on the DirectAccess server for Windows 7 clients to connect. In theory the client should be able to build the chain, but from experience I can tell you that it doesn’t. :/ If you have any certificate chain issues at all the client will often show a “certificate not trusted” error on the IP-HTTPS listener.
ChuckTesta
/ November 7, 2018Hi
On renewing our IPHTTPS cert we’re now getting 0x800b0109.
Running one online SSL cert checker, the results are that the DA server is not sending the intermediate cert, running another checker reports that the chain is fine.
How can we confirm that the intermediate cert is installed correctly ?
Richard M. Hicks
/ November 9, 2018Odd that you’re getting different results from different tools. If you haven’t done so already, try using the Qualys SSL Labs server test site. If it indicates certificate chain issues, I’d expect it is right. You could also confirm this by taking a network trace and looking at the TLS handshake. Either way, if you suspect a chain issue the best thing to do is ensure you have all of the correct intermediate certificates installed on the DirectAccess server, and importantly they are installed in the correct stores. For example, you will have issues if the root and/or intermediate certificates are installed on the Personal store.
Andy Nicholls
/ April 30, 2019Stumbled across this article as I have the issue where all self signed certs have expired. It’s a set-up I’ve inherited, so no idea how to fix it! NLS, IPHTTPS and DA-RADIUS-Encrypt certificates (all self-signed) have expired and I’m struggling to see how I re-generate these via New-SelfSignedCertificate PowerShell command. Any help appreciated.
Richard M. Hicks
/ May 1, 2019Hi Andy. I have a PowerShell script that clones these certificates and automatically updates the DirectAccess configuration. Reach out to me directly and I’ll be happy to share it with you. 🙂
Richard M. Hicks
/ May 2, 2019Decided to publish the PowerShell script I created to renew expired or expiring DirectAccess self-signed certificates. Details here: https://directaccess.richardhicks.com/2019/05/02/renew-directaccess-self-signed-certificates/.
Andy
/ May 29, 2019Hi Richard
Thanks for this!! Only just got round to look at this issue again. Life in MSP!!
I’ll take a look at the article and let you know either way.
Apologies for the late reply 🙂
Welcome to the world of Hemant!!!
/ July 26, 2019Hi Richard,
Just a little question. If i replace IP-HTTPS certificate…would it impact client PCs which are already connected to Direct Access.
Richard M. Hicks
/ July 26, 2019It depends. If you are currently using a self-signed certificate, then renewing the certificate or replacing it with a public SSL certificate will be disruptive. However, if you are currently using a public SSL certificate and need to renew or replace it, the impact is minimal. Clients may be momentarily disconnected when you make the change but they’ll reconnect immediately. Users may not even notice the brief loss of connectivity.
Shane
/ September 18, 2019Hi Rich, I have a question, I have renewed Self-signed certs recently.
but some has an issues it keeps connecting, Once i dig deep i found out some users still replacing new one with old expired certificates which i cannot find anywhere even in GPO.
What is the issue you think?
Richard M. Hicks
/ September 21, 2019Not sure what’s up there. Have to assume they are getting an old GPO?
andozane
/ January 20, 2020Thank you for the write up…question…in a load balanced environment, what happens if I only update the new SSL Certificate on one of the servers in the group? Would it still function?
Richard M. Hicks
/ January 20, 2020Yes, it will work assuming you are bridging SSL to to your VPN servers and not terminating SSL on the load balancer.
andozane
/ January 29, 2020Thank you for your response…you are so appreciated!
OK, another quick question, after doing these steps, how do you really confirm clients can still connect? Do they need to do a gpupdate to get the updated client GPO then test connection? Speaking of, where do you identify in the GPO the new certificate being used?
Thanks 🙂
Richard M. Hicks
/ January 30, 2020Clients don’t have to do anything to reconnect after updating the SSL certificate. The certificate is public and already trusted, so they’ll happily connect any time. There’s nothing in the GPO that has any information about your certificate. That is only required when you use self-signed certificates (which isn’t recommend and not supported for load-balanced or multisite configurations).
Gary Schrock
/ June 9, 2020Just as a note, we ran into this issue today ourselves because we’re using self signed certificates (it’s something that I’m trying to get away from, but haven’t gotten dealt with yet). Given our current work from home situations, reading this definitely had me somewhat panicked over how I could get this fixed since we didn’t really have an alternative to get people connected in some other way to do a group policy update.
However, what I did discover is that if you export the IP-HTTPS and NLS certificates, send them to the client machine, and then import them on the client machines into the trusted root certificates, this will allow the configuration to start working again. This does require someone on the client end to have administrative access on their machine. This may not be an ideal solution, but in our case it’s something of a life-saver.
Richard M. Hicks
/ June 9, 2020It’s best to avoid using self-signed certificates for production use, but if you are forced to do so this is a good workaround. Not ideal, but it works. 🙂
Jonathan
/ June 15, 2021Hi Richard,
We have an environment with two Root CAs, we are migrating clients from one to another, we noticed that DA only allows one Root CA on computer certificate settings. What would be the alternative to migrate clients from one CA to another and keep connectivity with the DA? Our clients are mostly Windows 10.
Richard M. Hicks
/ June 17, 2021Reach out to me directly and I’ll provide you with some documentation. Thanks!