AVD SSO with Internal Certificates?
I am helping another team set up AVD SSO and I noticed that its using a self-signed certificate. I've been searching around for information on using an internal CA for the certificate since it is trusted and also available to use. Does any one have any documentation or information I can be pointed to regarding using the internal CA for the certificates instead of the self-signed ones? Just to note, we do not want to use ADFS at all on this setup. I did see some articles about setting up SSO with ADFS and that wouldnt apply to me. thanks in advance! Chris
Lost access to your Root CA in your 2-Tier PKI? Don’t worry, Use Cross Signing to Recover!
Hi there, this is Byron from the Microsoft Directory Service Support team. Today, I would like to share a new method to recover your PKI environment. Imaging how frustrating it would be if we lost our Root CA forever, such as a root certification authority VM was accidentally deleted, or the machine of the Root CA got into a no boot state with no valid way to recover it via backup! Also imagine that you did not backup the Root CA private key or database and have no way to recover. A traditional method would be rebuilding the whole PKI infrastructure from scratch. But there is another way which could save us a lot of time and effort (Good news to us! 😊) . How If it is a two-tier PKI, and the Intermediate CA Server is the one issuing certificates to the environment, and we still have access to the Intermediate CA Certificate with private key, we can build another Root CA, and “link” the Intermediate CA Server to the new Root CA. The steps are simple, just renew the Intermediate CA server with “Same Key pair” with this new Root CA. A high-level diagram below: In fact, this is like the Concept of “Cross Signing”; the newly issued Intermediate CA Certificate could be considered as a “Cross Certificate” as well. Cross Signing is typically used to make one PKI hierarchy chains up through another hierarchy, even when originally it was not configured that way. This technique is designed for a leaf certificate to build a different certificate verification chain, in case one of the chains fails, allowing certification verification to succeed. Cross signing is also used by public CA companies to start their business which we will discuss more in a later section. Here are detailed steps on how to do this: On the Intermediate CA Server. Open the Certification Authority Management Console. Right click on the CA Name node -> All Tasks -> Renew CA Certificate. Renew Intermediate CA server with “Same Key pair” to create the Certificate renewal request file: Submit the certificate request file (.req) on the newly Deployed Root CA Server, issue it, and go to: Issued Certificates node-> Right click on issued Certificate -> All Taks -> Export Binary Data… -> Save as .cer file. Copy this .cer file to the Intermediate CA. On the Intermediate CA Server. Install the newly issued Intermediate CA certificate issued by the new Root CA. The existing issued Leaf Certificates verification should continue to work and chain up to the new Root CA. We can use command Certutil -urlfetch -verify c:\certificate.cer > certificate.txt to export the certificate verification and chain build information. Previous Chain: Leaf certificate: 5700000006d907d38be599e05a000000000006 Issuer: CN=ContosoRootCA01,DC=contoso,DC=com (Previous corrupted Root CA) Current Chain: Leaf certificate: 5700000006d907d38be599e05a000000000006 Issuer: CN=ContosoRootCA02,DC=contoso,DC=com (New built Root CA) How and Why So exactly what is “Cross Signing”? Let’s see the following story (I found this story online): A long time ago (maybe not that long 😊), there was a Certification Authority company called LetsEncrypt. When they started their business, they generated their own 'ISRG' Root CA Certificate (ISRG Root X1). However, it takes time for the industry to accept new Root Certification Authorities. They could not wait that long to start their business, as this might have taken years. They deployed an Intermediate CAs first (LetsEncrypt X3 and LetsEncrypt X4) and used a popular public Certification Authority (DST Root X3) to sign those Intermediate CA Certificates. This allowed them to start their business immediately and issue Leaf Certificates to customers without waiting for the world to accept their own Root CA. So, the Certificate Chain back then was DST Root X3 --> LetsEncrypt X3 / LetsEncrypt X4 --> Leaf Certificate. After 5 years of hard work, the market accepted their Root CA (DST Root X3) and added it to all kinds of products’ Trusted Root. They signed their Intermediate CA certificates with their own Root CA. Now, another chain is available: ISRG Root X1 --> LetsEncrypt X3 / LetsEncrypt X4 --> Leaf Certificate. How come the same Intermediate CA can be chained up to different Root CAs? The magic trick is the Intermediate CA Certificate kept the “Same Asymmetric Key Pair” when it got signed by both DST Root X3 and ISRG Root X1. As you can see from the above screenshots, the issuer is different, and they are two different intermediate CA certificates, but the trick here is the Same Key Pair, even though they were signed by different Root CA’s, aka “Cross Signing”. Another key point here is not all Certificate Chains rely on the AIA path. Another common Certificate chain build method is Key match using AKI/SKI and PKCS#7 which means the server side sends both Leaf Certificate along with Intermediate CA to the client for verification, Client does not need to build chain to Intermediate using AIA. You can refer to this document for more information about this story: https://scotthelme.co.uk/cross-signing-alternate-trust-paths-how-they-work/ There is another “Cross Sign” method targeting the Root CA Certificate itself. The concept is a little bit different: Using one Root CA Certificate to sign another Root CA Certificate. What is the usage scenario? Why do we need this? Scenario 1 Here is a story: In a large corporation, deploying Root CA certificate to all devices might be challenging. It could be time-consuming and might take a lot of administrative effort. Therefore, during the time periods when large corporations renew their Root CAs, they must find a way for newly issued Certificates under the renewed Root CA start to work as soon as possible. The idea is to sign the new Root CA certificate using the old Root CA Certificate, so the chain could be: leaf Certificate --> Intermediate CA -> New Root CA (Signed by Old Root CA)--> Old Root CA. Because devices should trust Old Root CA already, the new Leaf Certificate works immediately after renewal without waiting for new Root CA Deployed to all devices. Scenario 2 Another scenario is once the New Root CA is deployed to the environment, the company wants to remove the old Root CA certificate from the Devices’ trusted Store for company policy reasons. How can the existing Certificate continue to work if they are not yet expired and issued by old Root CA Certificate? The solution is also Cross Certificate: Create a CA Certificate with old CA key pair but signed by the new Root CA Certificate. The chain build would be below: Existing Issued Leaf Certificate --> Intermediate CA --> Old CA Certificate (cross signed by new Root CA) --> New Root CA. In fact, Active Directory Certificate Service supports this and will generate Cross Certificates by default when renewing a Root CA with a new key. Remember that when we renew the Root CA, there will be two additional CRT files called XXXXX (0-1).crt and XXXXX(1-0).crt. These certificates(.crt) are Cross CA Certificate’s. (0-1) is the New Root CA Certificate signed by Old Root CA Certificate. (1-0) is the old Root CA Certificate signed by new Root CA Certificate. They are used for the above Scenario 1 and Scenario 2 As you can see, the Root CA Certificate has an AKI (Authority Key Identifier), which means it was signed by a CA and an SKI (Subject Key Identifier) that matches it. Of course, in Active Directory, we rarely see the deployment of the Cross Certificate, because for Windows devices, the Active Directory is sufficient to quickly deploy new Root CA Certificate to Windows domain members. Summary The common method to perform PKI disaster recovery when the CA private key and database cannot be restored involves rebuilding the entire PKI Hierarchy PKI from scratch, and replacing every single certificate used by applications and servers. While the common method mentioned above is still valid, the “Cross Signing” method illustrated in this blog offers an alternative quick method to recover our PKI Hierarchy. This could potentially save us from spending a lot of disaster recovery time & administrative effort 😊.
IoT Edge certificate renewal
Hi all, We are currently implementing an IoT Edge on a lot of Devices which will be at remote locations. We have cleared out that IoT Edge can use up to 3 certificates: Certificate to perform the TLS communication with IoT Hub Device certificates for internal use with modules, leave devices, etc. DPS (Optional is you use certificates) We are currently looking for a solution for point 1 and 2. 1. We understand that this can be solved with keeping IoT Edge up-to-date, but how do perform this is these devices are Remote and we have a lot of them? I know this will not happen that often that this certificate will expire but still it can, so we want to be prepared. 2. Device certificates should also be renewed from time to time. How can you also orchestrated form IoT Hub? We currently where thinking of building a module, but when the device comes online again after some time and in the main time, the certificate has expired, than the module is not able to talk to IoT Hub. Or do you just install a device certificate a installation which will have an expiration date longer then the expected device lifetime? Thanks for the help and insights on this topic. Kr, StevenTrusted certificate profile in Intune Stuck at Pending
We need to deploy our Root CA and subordinate issuing CA Certificates to our Intune managed AAD only devices to support SCEP. We created a trusted certificate profile in Intune to provision these certs but however comma this profile is stuck at pending... How do I troubleshoot what is going on? Microsoft how have I failed you 😞 Intune supports use of the Simple Certificate Enrollment Protocol (SCEP) to authenticate connections to your apps and corporate resources. SCEP uses the Certification Authority (CA) certificate to secure the message exchange for the Certificate Signing Request (CSR). When your infrastructure supports SCEP, you can use Intune SCEP certificate profiles (a type of device profile in Intune) to deploy the certificates to your devices. Configure infrastructure to support SCEP certificate profiles with Microsoft Intune | Microsoft Learn To use a SCEP certificate profile, devices must trust your Trusted Root Certification Authority (CA). Use a trusted certificate profile in Intune to provision the Trusted Root CA certificate to users and devices.
