Managing MDM While Upgrading SHA1 Certs to SHA2

 

Managing an MDM environment in the middle of a corporate-wide certificate upgrade can get a little complicated. As an MDM admin, you not only have to make sure that MDM certificates are upgraded, but the certificates of other departments as well. An MDM environment may only consist of a few important certificates: the push certificates, SSL certificates, and possibly SSO certificates. Managed devices, however, will utilize certificates from other departments. An application department may require mobile devices to have root CA certificates installed. A network department may require mobile devices to have wifi or vpn certificates installed. All of these non-MDM departments will be responsible for setting up the upgraded certificates on the backend, but who’s going to be responsible for making sure end users can actually use them? Well, that responsibility will fall on the MDM team. Only an MDM admin will have the full visibility of enrolled devices to troubleshoot, upgrade, and action mobile device certificate upgrades.

 

Teamwork is key. Here is an example of some of the collaboration that must be done for a corporate-wide SHA1 to SHA2 upgrade (in regards to MDM):

  • While a security team can be tasked to stand up a new CA server and publish CRLs, the MDM team must work with them to validated network connections, CRL revocation checks, and SCEP pulls. Only MDM administrators will know how devices will connect to the CAs to obtain and renew certificates.
  • While a network team can be tasked to set up SHA2 connections on a Wifi or VPN environment, the MDM team must work with them to test device connections, device certificate installs, and plan out device certificate upgrades.
  • While an application team can be tasked to set up web application certificate upgrades, the MDM team must work with them to validate certificate chain trust evaluation.

In a way, a corporate-wide certificate upgrade puts the MDM department at the center of everything. Nothing can be done without verification from the MDM team, and users will not be upgraded without the actions of the MDM team. You can’t even validate or test without having the MDM team involved.

 

If you or your IT department ever decides to embark on a similar project, here is some advice: create a public timeline. You can use an Excel sheet, a project management application, whatever. Just put it up somewhere public, like a Sharepoint, so that everybody is on the same page. Log all of the required actions, dates, owners, statuses, impacts, and verification steps so that nobody loses track of what is going on. This will make the entire project move along a lot smoother, and prevent people from panicking!

My Easy Take On the SHA1 Certificate Issue

SHA1 is about to die. As a regular user, what is SHA1 and why should you care? Well, if you’re a regular person, you like to go onto the internet and browse websites. When you type in “google.com” into your browser, you will be connected to a server to access its resources. As long as you are actually connected to the right server, in this case a Google server, then you should have no problems. The issue is that there are ways to divert your browser to “false” Google servers, where your data can be compromised. How do you know that your browser is actually connected to a valid server? The answer is through certificates and encryption. That’s where SHA1 comes in.

SHA1 is an algorithm, but the only thing you need to know is that it is used to generate digital certificates. Web server administrators purchase these certificates from trusted third parties in order to prove that their web servers are legitimate. Once a web server is proven trust-worthy by a public third party, and your browser trusts that same third party, then your browser will know to trust the web server. For example, Paypal web servers are trusted by the third party Verisign, which is trusted by many browsers. When your browser connects to https://www.paypal.com, and sees that the web server is presenting a Verisign certificate, then it will know that it is connected to a valid Paypal server. A lot more info can be found here.

Now we know what SHA1 is, why should we care that it’s “dying?” Well, if SHA1 “dies,” then all of those certificates made by it will be un-trustworthy. If you connect to a web server that has a SHA1 certificate, you won’t know for sure that you are connected to a valid web server. It could be a malicious server trying to get your information. ArsTechnica released an article this morning detailing a brute-force attack that can generate duplicate SHA1 certificates. The actual study gives the technical details:

More recently, a collision for the full compression function underlying SHA-1 was obtained by Stevens et al. [37] using a start-from-the-middle approach and a highly efficient GPU framework (first used to mount a similar freestart attack on the function reduced to 76 steps [18]). This required only a reasonable amount of GPU computation power, about 10 days using 64 GPUs, equivalent to approximately 257.5 calls to SHA-1 on GPU.

People have been predicting that the SHA1 algorithm could be broken as far back as 2005, but it wasn’t only until the last couple of years that IT departments and companies all over the world started upgrading to the more secure algorithm SHA2. In 2014, 98% of all websites still used certificates generated by SHA1. In late 2016, still over 1/3 of all websites were using SHA1. One of my biggest projects right now is to upgrade all the SHA1 certificates of a global company to SHA2. In my case, the focus isn’t so much for security, since all of their external websites are already using SHA2, but for user experience. In the near future, browsers will show nasty error messages if a SHA1 certificate is detected. It is in the best interest of all companies and IT departments to upgrade from SHA1 as soon as possible.