none
Replacing existing IP-HTTPS DirectAccess server/client certificates with new PKI? RRS feed

  • Question

  • Hello,

    We have deployed a Server 2012 R2 DirectAccess infrastructure, single server and we only use IPHTTPS. Our clients are a mix of Windows 7 and Windows 10.

    • Our DA server uses a public certificate on the IP-HTTPS tunnel
    • We've deployed a new PKI to replace our existing one. 
    • I need to migrate our DA implementation (server/clients) to use certificates from the new PKI.

    What would this process be?

    I think I need to push computer certificates from the new PKI to all of our domain joined laptops that are enabled for DA before I change the certificates on the DA server itself otherwise how else can clients connect back?

    1. Are there any issues that could happen if a client computer has two certificates, one from old PKI and one from new? Will this break existing DA connectivity or will DA know which certificate to use?
    2. When I change the certificate on the DA server, to the new one from our new PKI, it will probably need to apply these updates to the GPOs; now will the DA clients need the updated GPO settings along with the updated certificates to work?

    How can I do this with minimal downtime to our DA clients? I don't want to break DA connectivity for our mobile users on laptops, but i need to replace our existing PKI and get the DA infrastructure to use the new PKI.

    Anyone done this before?


    • Edited by techy86_ Sunday, December 18, 2016 4:49 PM
    Sunday, December 18, 2016 4:41 PM

Answers

  • I'm gonna have to disagree with what has already been said on this one (sorry!)

    I have done this a few times, and the reverse it actually true:

    If you are only changing the public SSL certificate for IP-HTTPS, this change can be made on the DA server at any time. As long as you continue to use a certificate from a public CA, the clients will continue to trust it, and all of your clients will continue to work just fine. This is something that a lot of companies have to do every year and they never require for the computers to come back into the office, because you aren't making any changes to the client GPO.

    On the other hand - when you want to change to a new internal CA server that manages the IPsec (machine) certificates - this is a much bigger deal. Your process is correct, you definitely want to get the CA online and then issue the new machine certificates to all of the client computers first, before making any changes in the DA config. Yes, the clients will continue to function just fine like this, having two different certificates, that doesn't bother them.

    Then comes the tricky part, cutting over for the DA configuration to USE the new certificate from the new CA. You obviously need to issue a new certificate from the new CA to the DA server, and then you visit Step2 in the DA config and tell it to point to the new CA server. At this point all remote DA client computers will stop connecting. This is because your DA server is now validating client certificates to the new CA, and NO LONGER validating any client certificate requests against the old CA. All of the client computers think they still need to chain to the old CA, and so they break. In order to get those clients connected again, unfortunately they will need to connect to the corporate network some other way in order to grab their new GPO settings telling them to authenticate against the new CA.

    If you absolutely have no way of bringing all the machines into the office or connecting them to a VPN to pull down the new GPO setting or something like that, then the only clean way to migrate them over is to build a new DA server in parallel to your existing one, get it all up and running with new certificate from the new CA, and then do a live migration of users from the old DA server to the new DA server, as this is possible to do for remote clients without requiring them to come into the office.

    Sorry to have to deliver bad news on a Friday! :)

    • Marked as answer by techy86_ Friday, January 6, 2017 6:36 PM
    Friday, January 6, 2017 4:17 PM

All replies

  • Hi,

    You are right about the client side. You first need to make sure each clients get a new Computer certificate issued by the new PKI environment. Once you are sure every client has one (a second one actually) it is safe to change this in the DirectAccess configuration. I have done this before and it should work properly.

    Changing the certificate on the Direct Access Server is another story. Are you talking about the Computer certificate or the SSL certificate (for IP-HTTPS)? You can change the computer certificate on your DirectAccess Server(s) once your clients trust the publisher. Like your clients that is ok too. But... when you change the SSL certificate (used for IP-HTTPS) which is probably a public SSL certificate; then your clients have to connect to the internal network to receive a new GPO. Although as far as I can remember, because that was a while ago for me.


    Boudewijn Plomp | Conclusion FIT

    Please remember, if you see a post that helped you please click "Vote as Helpful", and if it answered your question, please click "Mark as Answer". This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, December 20, 2016 10:23 AM
  • Hi Boudewijn,

    We are not replacing the IP-HTTPS certificate.

    Our IP-HTTPS uses a 3rd party vendor who's CRLs are readily available and according to best practices this was the suggested route.

    We are wanting to replace the computer certificate (authentication); which is currently using a certificate from a internal PKI that we want to retire, so we want to replace this certificate with a new one. However I was told that doing this will cause disruption because all clients need to receive the updated information via GPOs.

    But from what you are saying, it sounds like it is the opposite; as long as I get a new computer certificate out to my domain joined computers from the new PKI (second certificate) and THEN replace the root/intermediate CA that DirectAccess uses, this will not cause an outage?

    The reason I ask is because I also posted on ServerFault and the response I got was different.

    http://serverfault.com/questions/821380/directaccess-and-renewing-ssl-with-new-pki/821511#821511

    Tuesday, December 20, 2016 5:48 PM
  • You can safely change the computer certificates of your DirectAccess Clients and DirectAccess Server(s) as long as you make sure you do it in the right order at mentioned. With the exception of the external IP-HTTPS certificate.

    Boudewijn Plomp | Conclusion FIT

    Please remember, if you see a post that helped you please click "Vote as Helpful", and if it answered your question, please click "Mark as Answer". This posting is provided "AS IS" with no warranties, and confers no rights.



    Sunday, December 25, 2016 11:15 AM
  • I'm gonna have to disagree with what has already been said on this one (sorry!)

    I have done this a few times, and the reverse it actually true:

    If you are only changing the public SSL certificate for IP-HTTPS, this change can be made on the DA server at any time. As long as you continue to use a certificate from a public CA, the clients will continue to trust it, and all of your clients will continue to work just fine. This is something that a lot of companies have to do every year and they never require for the computers to come back into the office, because you aren't making any changes to the client GPO.

    On the other hand - when you want to change to a new internal CA server that manages the IPsec (machine) certificates - this is a much bigger deal. Your process is correct, you definitely want to get the CA online and then issue the new machine certificates to all of the client computers first, before making any changes in the DA config. Yes, the clients will continue to function just fine like this, having two different certificates, that doesn't bother them.

    Then comes the tricky part, cutting over for the DA configuration to USE the new certificate from the new CA. You obviously need to issue a new certificate from the new CA to the DA server, and then you visit Step2 in the DA config and tell it to point to the new CA server. At this point all remote DA client computers will stop connecting. This is because your DA server is now validating client certificates to the new CA, and NO LONGER validating any client certificate requests against the old CA. All of the client computers think they still need to chain to the old CA, and so they break. In order to get those clients connected again, unfortunately they will need to connect to the corporate network some other way in order to grab their new GPO settings telling them to authenticate against the new CA.

    If you absolutely have no way of bringing all the machines into the office or connecting them to a VPN to pull down the new GPO setting or something like that, then the only clean way to migrate them over is to build a new DA server in parallel to your existing one, get it all up and running with new certificate from the new CA, and then do a live migration of users from the old DA server to the new DA server, as this is possible to do for remote clients without requiring them to come into the office.

    Sorry to have to deliver bad news on a Friday! :)

    • Marked as answer by techy86_ Friday, January 6, 2017 6:36 PM
    Friday, January 6, 2017 4:17 PM
  • Hi Jordan,

    Thank you for your detailed post, this reaffirms my knowledge on this.

    We do use a public CA on the IP-HTTPS interface that has its CRLs publicly available so our clients can connect without issues; and I have changed this certificate in the past all OK. It would be terrible if changing that certificate caused issues!

    Since we are moving to a entirely new PKI (SHA2); I have issued Computer Certificates to our clients using this PKI and they also have the Computer Certificates from the old PKI so stuff keeps running.

    The last server to update before I can sunset the old PKI is the DA server and with your information this makes the planning process easier. I already plan to update the internal certificate used when we can get most of our computers on the network, giving users enough time and notice to bring the computer on the network for a GPO update is what we're going to do.

    There will be a few that won't be able to come in (they live too far), so according to your post one possibility is to use VPN. Our DA server is also setup as a VPN server (SSTP VPN), can GPOs be updated on a client machine when they create the VPN tunnel? I though some GPOs update only during a reboot of the machine (computer policies) and some update when you run gpupdate /force (user policies).

    Most of the DA GPOs are computer configuration changes, so a reboot is required; but when you initiate a reboot the VPN connection will be disconnected?

    As this next part is out of the scope of the original post, I am marking your post as the best answer, thank you.

    Friday, January 6, 2017 6:36 PM
  • I'm glad the info helped!

    You are on the right track to getting this done properly. For those machines that are remote, yes you can definitely connect them via VPN and then run a gpupdate /force. This will pull in the new DA settings. Those new settings might not take effect immediately, the user may have to reboot after doing the gpupdate /force, but DA should then start working once again.

    Good luck!

    Friday, January 6, 2017 8:32 PM
  • READ BELOW FOR ALTERNATE METHOD WITHOUT LOSS OF CONNECTIVITY!

    To clarify, you can do this live for anyone going through this scenario where they are replacing/upgrading/changing their CA.

    Since DA is primarily GPO based, before you expire and decommission your old CA box you can edit bot the Client and Server GPO's for DA to include your new CA (intermediate or root) as another approved authentication in conjunction to your existing one. This way when you officially remove the old CA the GPO already allows to auth with the new certs, so you can renew the certs (remove old CA template) and voila everyone continues on their merry way. You can clean up at your leasure.

    The settings in the GPO you need to adjust are:

    Computer Configuration > Windows Settings > Security Settings > Windows Firewall > Connection Security Rules

    DirectAccessPolicy-DaServertoCorp

    DirectAccessPolicy-DaServertoInfra

    Under the Authentication Tab > Customize > First Authentication > Add

    Add your new CA cert weather root or intermediate

    Repeat the process for the Client DA GPO same location just will be ClienttoCorp and ClienttoInfra

    Force a gpupdate or wait 15 mins for your DA clients and bam either cert will work. Just make sure you push the new client auth certs from your new CA to the workstations, once comfortable you can use the DA wizard to officially set just the single cert or edit the GPO's above again to remove the old cert.

    No need for a side by side or loss of connectivity in this case...

    I just had to do all this because our CA was expiring in 6 days, and had our first cert renewals kick in replacing the old cert with new from the new issuing CA and DA connections stopped working.

    This is much faster than trying to figure out some weird way to apply a gpo or have people VPN in to get new GPO.

    Frankly speaking this should have a been an option off the bat (primary cert/alt cert) but whatever, much better solution than provided by others.


    Wednesday, October 4, 2017 8:27 PM
  • Thanks for this, John. What you said made a lot of sense, and I can confirm that it works well.

    I've just finished up using this method to migrate to a new internal PKI without disturbing existing DA clients.

    A few observations:

    1. Should go without saying, but back up the DirectAccess GPOs before you attempt any of this process
    2. When modifying the Connection Security Rules in the DA Client and Server GPOs, it'll warn about some connection filtering settings that aren't available in the Group Policy view of the rules. I ended up just adding the second CA, and then cancelling out without hitting OK on the properties. This still ended up adding the CA to the GPO, but didn't break anything. This might not make sense if you're just reading it now, but it should make sense when you're in the process of modifying the GPOs
    3. Make sure that your DA server has a certificate from the new PKI that contains both Server Authentication and Client Authentication EKUs before applying the final config via the DirectAccess/Remote Access Management GUI
    Thursday, November 22, 2018 12:10 AM