Sophos Mobile Control 7.0.10, Getting error with SCEP & NDES

Question

When I try to push a profile out to an iOS device, I keep getting this error 
 
 Anyone have any idea how to troubleshoot this down further? It also doesn't appear to be obeying the login and password you give it under SCEP setup. 
 iOS MDM commands

Name 
 State 
 Error description 
 Insert date

InstallProfile 
 Error 
 [4001][MCInstallationErrorDomain]Profile Installation Failed [4001][MCInstallationErrorDomain]Profile Failed to Install [1009][MCProfileErrorDomain]The profile &ldquo;SCEP Test (1)&rdquo; could not be installed. [22013][MCSCEPErrorDomain]The SCEP server returned an invalid response.

Charles Biggers · Answer

I fixed that issue. It has to due with two changes I made I think. 
 
 1. I moved the NDES to its own VM and removed it from the CA & AD controller. 
 
 2. I read an article PeterRist from this forum gave me and made changes to URL lengths and a few other things. 
 
 After making these changes i'm able to send the SCEP profile down to the iPhone. I think Sophos should probably add these steps for IIS changes to their article on setting up SCEP. 
 
 Article 
 https://blogs.technet.microsoft.com/tune_in_to_windows_intune/2014/04/25/part-2-scep-certificate-enrolling-using-configmgr-2012-crp-ndes-and-windows-intune/

Jan Wachsmuth · Answer

Although I saw that the problem is solved already, I like to add some notes to the IIS log output that was provided by Charles Biggers and add some additional infos for troubleshooting. It may be helpful for others. 
 The first three requests shown in the IIS log are send by the MDM to get the challenge (the one-time token) from the SCEP/NDES server. This request must be send by SSL (you can see port 443 ) to be secure (enforced by setting on the IIS). The MDM has to authenticate on this URL and the challenge will be secured by SSL as well. The response codes from the IIS server, e.g. 401, 301 and 200 are important as well. As usual with authentication for a web page, the server responds with &ldquo; 401 &ndash; Unauthorized &rdquo; first, then the client sends the same request again, but with authentication (you can see the logon name SPECTRA\Administrator). I believe that due to the missing / at the end, the server responds with &ldquo; 301 - Moved Permanently &rdquo; and the correct URL is forwarded with the &bdquo;Location&ldquo;-Header field in the response. Finally the client sends another request that is responded with &ldquo; 200 &ndash; OK &rdquo; 
 2017-08-16 22:02:52 10.10.24.10 GET /CertSrv/MSCEP_ADMIN - 443 - 10.10.24.20 Apache-HttpClient/4.5.2+(Java/1.8.0_112) - 401 2 5 174 2017-08-16 22:02:52 10.10.24.10 GET /CertSrv/MSCEP_ADMIN - 443 SPECTRA\Administrator 10.10.24.20 Apache-HttpClient/4.5.2+(Java/1.8.0_112) - 301 0 0 191 2017-08-16 22:02:52 10.10.24.10 GET /CertSrv/MSCEP_ADMIN/ - 443 SPECTRA\Administrator 10.10.24.20 Apache-HttpClient/4.5.2+(Java/1.8.0_112) - 200 0 0 214 
 The MDM cuts out the challenge from the webpage. You may verify the URL with a browser, e.g. 10.10.24.10/.../ and have a look on the messages on that web page. It could happen, that the cache of challenges is exhausted or there is a problem. The number of concurrent challenges as well as their lifetime can be set in the registry, see e.g. https://social.technet.microsoft.com/wiki/contents/articles/9063.network-device-enrollment-service-ndes-in-active-directory-certificate-services-ad-cs.aspx#Configuring_the_Network_Device_Enrollment_Service 
 Then the MDM creates the configuration for the mobile device, e.g. a .mobileConfig file for an IOS device and forwards the file to the device. The MDM acts as a reverse proxy to protect the IIS/CA/NDES server. On the IIS you should see three requests that were forwarded by the MDM (client IP address 10.10.24.20 belongs to the MDM). According to the SCEP specification these requests are send by HTTP not SSL, see https://tools.ietf.org/html/draft-gutmann-scep-06#section-4 . This may indicate a problem, especially with the third message. 
 At first the mobile device requests the CA certificate and intermediate certificate (if used) with a &ldquo;operation=GetCACert&rdquo; message. Depending on the type of CA (intermediate, or single/root) and if RA is involved, the answer is either a single X.509 certificate or a CMS container. 
 2017-08-16 22:02:55 10.10.24.10 GET /CertSrv/MSCEP/ operation=GetCACert&message=corp-EMU-CA 443 - 10.10.24.20 Java/1.8.0_112 - 200 0 0 78 
 With a Microsoft CA/RA, you may verify the response by entering the URL, e.g. 10.10.24.10/.../ into your browser. Save the response and rename it to mscep.p7b, then open the file. You should see a security container with some certificates. Verify that the dates (lifetimes), serial numbers of the CA, subordinate CA (if used) and two RA certificates are correct. 
 Then the mobile device requests the CA capabilities, see https://tools.ietf.org/html/draft-gutmann-scep-06#section-3.5.2 . Again, with a browser you can verify the response &ndash; it&rsquo;s just a plain text file. 
 2017-08-16 22:02:55 10.10.24.10 GET /CertSrv/MSCEP/ operation=GetCACaps&message=corp-EMU-CA 443 - 10.10.24.20 Java/1.8.0_112 - 200 0 0 22 
 With the two messages described above, you should normally not see problems. Here we see &ldquo; 200 &ndash; OK &rdquo; as a response and it&rsquo;s easy to verify the content. The third message is the request for a certificate. The request is coded with the message operation=PKIOperation&message= and contains a very long URL. It&rsquo;s very difficult to decrypt the message, although not impossible, if you are an expert. The enrollment request is coded as a PKCS#7 message with base-64 format and encoded to be send as a URL, e.g. the trailing &ldquo;==&rdquo; are converted to 3D%3D (some special characters are encoded). For troubleshooting purpose the response code from the server is important: 400 &ndash; bad request . 
 2017-08-16 22:02:55 10.10.24.10 GET /CertSrv/MSCEP/ operation=PKIOperation&message=MIAGCSqGSIb3DQEHAq . . . 9rm9LDTAji2uJKVMLZQgAAAAAAAA%3D%3D 443 - 10.10.24.20 Java/1.8.0_112 - 400 0 0 15 
 I&rsquo;m not sure about the reason, but I know that the IIS needs to be configured via registry as well as IIS manager to handle these long URLs. The link provided by Charles Biggers is very good and is the same that I had used. In my opinion you don&rsquo;t have to move NDES to its own VM. 
 On the Microsoft side, the options for debugging are limited, difficult to use, and the information that is presented is sometimes very confusing. You may enable logging (MSCEP.log in the Windows directory), although it may not help much. CAPI (Crypto API) logging can be enabled by Microsoft event viewer and may be more helpful, but sometimes overwhelming. You need to look into the details to get some useful information. See technet.microsoft.com/.../ff955644(v=ws.10).aspx for additional infos. 
 
 Some additional hints, if your output is different and you are stuck in the last step: 
 When you get a response code &ldquo; 200 &ndash; OK &rdquo;, to the last URL, but it still does not work, you may consider looking into the content of the response. You may copy&paste the URL into your browser, e.g. 10.10.24.10/.../ . . . 9rm9LDTAji2uJKVMLZQgAAAAAAAA%3D%3D (the whole content, of course). The response is a file that can be opened with an ASN.1 editor, e.g. https://www.sysadmins.lv/projects/asn1editor/default.aspx . A better option than to repeat the request would be to capture the original response and cut out the binary response with Wireshark, because the request contains the challenge that has a limited lifetime. 
 It&rsquo;s not too difficult to understand the response, when opened with an ASN.1 editor. Look for the following SCEP OIDs: 
 
 2.16.840.1.113733.1.9.2 scep-messageType 
 2.16.840.1.113733.1.9.3 scep-pkiStatus 
 2.16.840.1.113733.1.9.4 scep-failInfo 
 
 Especially the last one is important. The numbers for failInfo are listed in the RFC, see https://tools.ietf.org/html/draft-gutmann-scep-06#section-3.2.1.4 : 
 
 badAlg (0) -- Unrecognized or unsupported algorithm identifier 
 badMessageCheck (1) -- integrity check failed 
 badRequest (2) -- transaction not permitted or supported 
 badTime (3) -- The signingTime attribute from the PKCS#7 authenticatedAttributes was not sufficiently close to the system time (see Section 3.1.1.6). 
 badCertId (4) -- No certificate could be identified matching the provided criteria 
 
 I got a &ldquo; badRequest &rdquo; which is quite unspecific, however I was able to rule out the listed other more specific options, e.g. badTime . 
 
 An additional approach to find the source of the problem might be to use the tool &ldquo; certreq &rdquo; to verify if SCEP is working in general without the MDM. See https://blogs.technet.microsoft.com/configmgrdogs/2015/08/24/so-you-want-to-test-your-ndesscep-certificate-enrollment/ for more information. I had to disable authentication on the admin page and to use plain http, but at the end I was able to see that a certificate was issued by SCEP. There is a little mistake in the explanation, because the certificate is issued after " certreq ... -submit ... " was executed, but otherwise it's a really good article and a nice way to see if SCEP is working. 
 If you have a MacBook (or other Apple device with OS-X), and an IOS device for testing purpose, you may download the .mobileconfig file (the template) from the MDM, and open it with Apple Configurator 2 . You have to modify subject , challenge , and the request URL - use real values instead of variables. Then forward the file to the IOS device, e.g. by email, and install the profile. 
 Regards, Jan