I logged into my home lab for the first time in a while and found that my MDM environment was no longer functional. After making sure the my MDM server was available externally, DNS records were all correct, and all MDM services were running, I checked the CA services. Yup, those were down. Not only that, but they weren’t starting up at all. I got the error above: “Unable to check revocation because the revocation server was offline.”
Didn’t I make all my CRLs public last time? I checked and yup, my intermediary CRLs were all available, and externally reachable. Uh oh. Do I need my root CRLs available too for this to work? It makes sense that the root CRLs have to be evaluated too, not just the intermediary.
I found this great blog post here at stealthpuppy and turned off the CA revocation check. That immediately solved my problem temporarily. But it didn’t solve my inherent problem: my CRL revocation checks were failing. It looks like the writer of stealthpuppy had the exact same problem I had, which was that the root CRLs were not updated and available.
Once I changed the root CRL expiration length and exported an updated CRL, all errors went away!
- “certutil –setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE” is the command used to disable CRL check and make the error message temporarily go away.
- “certutil –setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE” is the command used to re-enable CRL check.
- Make sure the CRL of every CA in the chain is made publicly available and updated.
- If needed, make the expiration of a CRL very long so you don’t have to bring up the root CA often.
- I had an NDES error after all of this as well. HTTP 500 error when trying to load mscep_admin. I solved that by re-installing NDES and then a reboot.
When it comes to browsing and self-signed SSL, it looks like there is a ton of wrong information online. I read everywhere from “you can’t use IIS to generate valid self-signed SSL certs for iOS” to “iOS 10 doesn’t support self-signed SSL certificates at all anymore.” Well what’s the truth? Turns out the truth is that a lot of people want to use self-signed SSL certificates on iOS, but just don’t know how to do it.
First things first, the iOS Safari browser verifies SSL just like any other browser. What does that mean? That means that the website that you’re visiting must have an SSL certificate installed, and that the SSL certificate must have been issued by a trusted Root Certificate Authority. Here’s how I was able to get my self-signed SSL set up using Windows Server 2008 R2:
Create a self-signed SHA-256 SSL Certificate
- Stand up a ROOT CA, generate a ROOT CA certificate, and then turn off this server for best practices.
- Stand up an Intermediate or Subordinate CA. Generate a CA certificate with this intermediate CA.
- You can’t use IIS to generate a SHA-256 certificate request directly. You will have to instead use the mmc.exe Certificate snap-in and certutil. In the mmc.exe Certificate snap-in, you’ll see an option to request a custom certificate. Click Create Custom Request.
- You will see the option to customize your request. Click Properties.
- When creating your custom request, make sure to fill out common name, valid country code, state, organization, organization unit, DNS, IP Address, and URL. The common name and DNS should include the website that you are securing. This is your chance to add alternative names as well.
- Make sure to export out your private key and choose at least SHA256. You don’t want to use SHA1 because it has been deprecated.
- Finish creating the custom request, then open command line.
- In command line, type this out: certutil -attrib “CertificateTemplate:WebServer” filelocation.req and then press enter.
- You will be prompted to choose an issuing CA. Choose your intermediary, and then you will generate a new certificate. It will prompt you where to save it.
- Now that you have a valid SHA-256 SSL certificate, take it to IIS where you can bind it to your default website. At this point your website has a valid self-signed SSL. However, your Root CA will not be trusted anywhere. You will have to make your Root CA certificate available for install in order for it to be trusted.
Make your Root CA certificate available for iOS install
- There are multiple ways to install a Root CA certificate onto an iOS device. One way is to email it to the device. That method is tedious in my opinion. A better method is to actually make an external link available, so that when you click it, the Root CA automatically installs onto your iOS device. The best way to do this is by creating a .mobileprovisioning file, or an iOS configuration file.
- On a Mac, open up Apple Configurator.
- Create a configuration profile. Under Credentials, choose your Root CA certificate.
- Create additional profiles for any intermediate CA certificates.
- When you have your mobileprovisioning files, put them somewhere external so that you can download them. For me the easiest way to do this was in the public IIS website: C:\inetpub\wwwroot\. I actually edited the
- Your server won’t be able to serve out those files by default. You’ll have to configure the IIS MIME type to allow those files to be served.
Make your CRLs publicly available
- You can configure your CA to publish your CRLs to your inetpub folder.
- Don’t forget to allow the CRL MIME type so that your server can deliver those files.
- Don’t forget to allow doubleescaping in IIS as well
You’re done! On your iOS device, navigate to your external site and install your CA certificates as mobile provisioning profiles. Then, when you navigate to your self-signed website, it will be trusted.