How to mitigate the Microsoft 365 Certificate Authority CA changes

Case



Microsoft's root CA "Baltimore CyberTrust Root" available at https://cacerts.digicert.com/BaltimoreCyberTrustRoot.crt as well as intermediate CAs Microsoft RSA TLS CA 01 and Microsoft RSA TLS CA 02 will be retired by October 2022.



The above root CA and intermediate CAs will be replaced by new root CA and intermediate CA authorities. For example, one new major root CA will be DigiCert Global Root G2.



The following endpoints are covered by the retired root CA and are expected to be impacted by this change:



- *.teams.microsoft.com

- *.skype.com

- *.skypeforbusiness.com

- *.groupme.com

- *.communication.azure.com

- *.operatorconnect.microsoft.com

This change will not affect certificates, domains, or services used in the China or Germany national cloud instances of Microsoft 365.



You need to determine if you will be impacted by this change and if so, to mitigate the Microsoft 365 Certificate Authority CA changes.



Solution



You must carry out the following steps to mitigate the Microsoft 365 Certificate Authority CA changes:



- Determine if your infrastructure and configuration will be impacted by this change or not. Your application will be impacted if it explicitly specifies a list of acceptable CAs. This is know as "certificate pinning". You must add the new root and intermediate CAs in your list of acceptable CAs, otherwise you will receive certificate validation errors and your infrastructure or application may not function properly.

- If your environment is impacted by the change then check the following areas for more details.

- In your firewall, allow the following Certificate Revocation List and Online Certificate Status Protocol URLs:- - http://crl3.digicert.com

- http://crl4.digicert.com

- http://ocsp.digicert.com

- http://crl.microsoft.com

- http://oneocsp.microsoft.com

- http://ocsp.msocsp.com

- http://www.microsoft.com/pkiops

- Check your Linux, Java, Android, IoT and offline Windows environments to ensure that they trust the new root CA and intermediate CA authorities. An example in the case of Ubuntu Linux is shown below.



- Check your application source code and configuration for dependencies or hard-coded properties referencing the old Microsoft 365 root and intermediate CAs. In such cases, where the software application overrides the standard operating system certificate validation and management, application re-configuration or re-coding may be needed.

Review the following Microsoft article for more details:



https://docs.microsoft.com/en-us/microsoft-365/compliance/encryption-office-365-tls-certificates-changes?view=o365-worldwide


https://stefanos.cloud/kb/how-to-mitigate-the-microsoft-365-certificate-authority-ca-changes/

Comments

Post a Comment

Popular posts from this blog

Acronis Cyber Protect 15 virtual machine backup not working when using shared mode virtual disks vhds

Image
Case When you apply and run an Acronis Cyber Protect backup against a virtual machine which is part of a guest cluster which makes use of virtual disk shared files of type .vhds (VHD Set), you run across the following error. Activity succeeded with warnings. Activity 'Preparing for backup of virtual machine' succeeded with the following warning 'Windows error: (0xC05CFF0A). The requested operation cannot be performed on the virtual disk as it is currently used in shared mode. Or the error may state something along the lines of: "Failed to open virtual disk file '.vhds'. Unknown format of the virtual disk." The same error as above can occur in virtual machine backup of virtual machines which include a .vdhx shared disk. Solution The above error is by design when you are attempting a virtual machine backup to virtual machine which does not have an Acronis backup agent installed, as per https://kb.acronis.com/content/68573 . According to Acronis, as of July 2
Read more

How to perform hardware health checks in Windows

Image
Case You need to perform an overall hardware health check in a Windows machine, running either a Windows client or a Windows Server operating system. This article provides guidance on the steps to carry out to perform hardware health checks in Windows. Solution Carry out the steps below. - Thoroughly check all Windows event logs (Application, System, Security) for any warnings or errors which may be related to issues you are experiencing with your Windows machine. - Check the device management mmc console by running devmgmt.msc. Ensure that you choose to show all hidden devices from the View menu. If you notice any exclamation marks next to any device, you will need to re-install its driver from the respective manufacturer to ensure that there afterwards no warnings in the device management console. - Check the health of all your disks , either HDD or SSD. Follow instructions in the following KB article for steps to follow to check your disk health: https://stefanos.cloud/kb/how-to-ch
Read more

How to resolve Group Policy error codes 8007071a and 800706ba

Image
Case You are running "Group Policy Update" on an OU inside the Group Policy Management Console in Active Directory but you are receiving RPC errors from your servers or domain-joined workstations, as shown in the example below. After a Group Policy Update, you come across Group Policy error codes 8007071a and 800706ba. This means that the local Windows Firewall is not configured properly to allow Group Policy (GPO) traffic. GPO traffic an be either remote GPO update or remote GP Resultant Set of Policy (RSOP) operations. Solution Option 1 Run gpedit.msc and create a new local group policy object which implements the following policies under Local Computer Policy --> Computer Configuration --> Windows Settings --> Security Settings --> Windows Defender Firewall --> Inbound Rules : The full configuration is shown below. After the above local group policies are configured on each domain server and workstation, you can start applying group policy objects to the dom
Read more