Troubleshooting Intune iOS SCEP Failure: No GetCACaps Request in IIS Logs

Table of Contents

Intune’s Simple Certificate Enrollment Protocol (SCEP) is a critical component for many organizations, enabling secure identity for iOS devices by automatically provisioning certificates. However, administrators occasionally encounter situations where iOS devices fail to enroll SCEP certificates, often manifesting as a missing GetCACaps request in the Internet Information Services (IIS) logs. This specific issue indicates a fundamental breakdown in the trust chain or certificate compatibility between the iOS device and the Network Device Enrollment Service (NDES) server. Understanding the intricate dance between these components is paramount for effective troubleshooting.

The GetCACaps request is a vital step in the SCEP enrollment process. It allows the requesting device (in this case, an iOS device) to query the NDES server for its capabilities, including supported hash algorithms, encryption algorithms, and certificate authority (CA) information. Without a successful GetCACaps request, the device cannot proceed with the certificate enrollment, leading to deployment failures and compromised security postures. This article aims to provide a comprehensive guide to diagnose and resolve such elusive SCEP failures on iOS devices.

Symptoms of SCEP Failure¶

Identifying the exact point of failure is crucial for efficient troubleshooting. In this specific scenario, the symptoms observed across various logs and device behaviors provide clear indications of the underlying problem. While SCEP failures can stem from numerous causes, the absence of a GetCACaps request narrows down the potential culprits significantly.

IIS Log Observations¶

When monitoring the IIS logs on your NDES server, you might observe a pattern that indicates a partial success but an ultimate failure. Specifically, you will typically find successful (HTTP 200 response) GetCACerts entries originating from the iOS devices. This means that the devices are able to reach the NDES server and retrieve the CA certificates, indicating basic network connectivity and initial trust establishment with the NDES server’s SSL certificate.

However, the critical missing piece is the subsequent GetCACaps request. Despite the successful retrieval of CA certificates, there will be no corresponding log entries for /?operation=GetCACaps from the affected iOS devices. This stark absence signals that the device, after receiving the CA certificates, encountered an issue preventing it from proceeding to query the server’s capabilities, which is the next logical step in the SCEP enrollment workflow.

Device Console Log Errors¶

Further investigation into the device console logs of the failing iOS devices will reveal more specific error messages that corroborate the IIS log observations. These errors usually point towards issues with the received certificate or the server’s response itself. Common error messages you might encounter include:

Desc : The Registration Authority's response is invalid.
May 23 14:15:36 -iPhone profiled[150] <Error>: SecTrustEvaluate [leaf AnchorTrusted]
May 23 14:15:42 -iPhone profiled[150] <Notice>: (Error) MC: Cannot retrieve SCEP identity: NSError:
Desc : The Registration Authority's response is invalid

These messages strongly suggest that the iOS device received information from the NDES server (likely during the GetCACerts phase) that it deemed invalid or untrustworthy. The SecTrustEvaluate error indicates a problem during the certificate trust evaluation process on the device, often related to the certificate chain presented by the NDES server or the certificates provided via the Intune trusted root profile. The “Registration Authority’s response is invalid” points directly to a protocol-level or certificate-level rejection by the iOS operating system, preventing further communication like the GetCACaps request.

Browser Test for GetCACaps¶

To further confirm the issue, you can perform a manual test using a web browser directly from an affected iOS device. Navigate to the NDES server’s SCEP endpoint with the GetCACaps operation appended: https://<NDESurl>/?operation=GetCACaps. When attempting this, you will likely observe an SSL failure in the browser.

Most browsers will initially display a generic message indicating that the SSL certificate is not trusted. Upon examining “More Details” or similar options, you will find a more specific error such as ERROR_WINHTTP_SECURE_FAILURE. This error is a strong indicator that the device is unable to establish a secure, trusted connection with the NDES server when attempting this specific SCEP operation, even if the GetCACerts operation seemed to work initially. This usually points to problems with the underlying certificates in the trust chain that the device is evaluating.

Delving into the Causes¶

The observed symptoms, particularly the SecTrustEvaluate errors and ERROR_WINHTTP_SECURE_FAILURE, consistently point towards issues with the cryptographic trust chain. Two primary scenarios are responsible for the absence of GetCACaps requests on iOS devices, both related to how certificates are established and trusted within the Public Key Infrastructure (PKI) for SCEP.

Cause 1: Mismatched or Incorrect Trusted Root Certificate¶

The most prevalent cause for this issue is a mismatch or misconfiguration in the trusted root certificate supplied to the iOS device via Intune, compared to the actual certificate authority (CA) certificates used by the NDES server. Specifically, this scenario arises when the certificate uploaded to the “Trusted Root certificate” profile in Intune is not the genuine root certificate, but rather an intermediate certificate.

To properly establish trust, the iOS device needs to receive the complete and correct chain of trust, starting from the trusted root. Intune’s trusted root profile is designed to push the ultimate anchor of trust to the device. If an intermediate CA certificate is uploaded instead of the true root CA certificate, the device will attempt to validate the SCEP enrollment certificate against this incorrect anchor. This creates a broken trust chain: the device receives an intermediate certificate from Intune, but when it connects to NDES, the NDES server presents its own certificate chain, which is anchored to a different or higher root CA. The device fails to reconcile these two chains, leading to the SecTrustEvaluate error and the inability to proceed with GetCACaps.

It is absolutely crucial that the trusted root certificate deployed via Intune precisely matches the root CA certificate that ultimately issues the intermediate CA certificate, which in turn issues the NDES server’s certificates. Any deviation or substitution with an intermediate certificate will break this fundamental trust model, especially on security-conscious platforms like iOS. While Android devices might exhibit similar issues, their specific error messages and handling of certificate chains can differ, leading to varied diagnostic output.

Cause 2: Unsupported Signature Algorithm¶

Another significant cause stems from the use of outdated or unsupported cryptographic signature algorithms within the root or intermediate certificates in your PKI. Modern operating systems and devices, especially iOS, are constantly evolving their security standards to deprecate weaker or less secure cryptographic primitives. If the certificates underpinning your NDES/SCEP infrastructure utilize such algorithms, iOS devices will reject them outright.

Specifically, root or intermediate issuing CA certificates that use RSASSA-PSS or SHA-1 as their signature algorithm are known culprits. SHA-1 has been cryptographically deprecated for many years due due to theoretical collision vulnerabilities, and while it might still function in some legacy systems, modern platforms like iOS actively block or warn against its use for establishing trust. Similarly, RSASSA-PSS is a more modern signature scheme, but it can sometimes cause compatibility issues if not properly implemented or if the device’s OS version does not fully support it in the context of SCEP. When an iOS device encounters such an unsupported algorithm in the certificate chain presented by NDES or delivered via Intune, it will fail the trust evaluation process, resulting in the same SecTrustEvaluate errors and the failure to make a GetCACaps request.

The Comprehensive Solution¶

Resolving the absence of GetCACaps requests requires a systematic approach, focusing on rectifying the certificate chain and ensuring cryptographic compatibility. The core solution involves reissuing certificates with supported algorithms and meticulously updating all components of the SCEP infrastructure.

1. Reissue Certificates with Supported Signature Algorithms¶

The primary step is to ensure that your entire certificate authority hierarchy (Root CA and any Intermediate CAs) uses robust and currently supported signature algorithms. SHA256RSA is widely accepted and recommended for its security and compatibility across modern platforms.

Steps for Reissuing Certificates (Conceptual):

• Review Current Algorithms: Before making changes, identify the current signature algorithms of your Root CA and all Intermediate CAs. This can be done by examining the certificates directly on your CA servers or by using command-line tools like certutil.
• Plan the Reissuance: Reissuing CA certificates is a significant operation that impacts your entire PKI. Plan carefully, considering the downtime and the impact on all certificates issued by these CAs. It’s often recommended to establish a new CA hierarchy if your existing one is very old or uses severely deprecated algorithms like SHA-1 throughout.
• Reissue Intermediate CAs: If your Root CA already uses a strong algorithm (e.g., SHA256), you may only need to reissue your Intermediate CAs using the same, strong signature algorithm.
  • On the Intermediate CA, generate a new certificate request (.req file) that specifies SHA256RSA as the signing algorithm.
  • Submit this request to your Root CA. The Root CA will issue a new intermediate CA certificate.
  • Install this new intermediate CA certificate on the Intermediate CA server.
• Reissue Root CA (If Necessary): If your Root CA uses an unsupported algorithm, the process is more complex, often involving bringing a new Root CA online or performing an offline renewal that changes the algorithm. This is a critical infrastructure task and should be performed by experienced PKI administrators with thorough planning. For most enterprises, the Root CA is offline, adding layers of complexity to such an operation.
• Update Certificate Templates: Ensure that any certificate templates used for NDES (e.g., the CEP Encryption and Exchange Enrollment Agent (Offline Request) templates) are configured to use a strong hash algorithm like SHA256 and are correctly set up for SCEP enrollment.

2. Update NDES Server Configuration¶

Once the new root and intermediate certificates are in place, the NDES server must be configured to trust and use these new certificates.

• Install New Certificates: Ensure that the newly issued Root and Intermediate CA certificates are installed in the appropriate certificate stores on the NDES server (Trusted Root Certification Authorities and Intermediate Certification Authorities, respectively).
• Update NDES SSL Certificate: If the NDES server’s own SSL certificate was issued by an intermediate CA that has now been reissued, you will need to obtain a new SSL certificate for the NDES website, issued by the new intermediate CA. This ensures a consistent trust chain from the NDES server itself.
• Verify SCEP Service Configuration: Confirm that the NDES service is configured to correctly reference the new certificate chain. This may involve reconfiguring the SCEP policy module or verifying its settings.
• Restart Services: After making any certificate changes, it’s essential to restart the IIS services (iisreset) and the NDES Connector service to ensure that the server loads the updated certificate configurations.

Figure 1: Conceptual SCEP/NDES Flow illustrating the certificate exchange.

3. Update Intune Trusted Root Profile¶

The newly issued root certificate must be deployed to iOS devices via Intune to establish the updated trust.

• Export New Root Certificate: Export the new Root CA certificate (in Base-64 encoded X.509 .cer format) from your Root CA.
• Create/Update Intune Profile:
  • Navigate to the Microsoft Intune admin center.
  • Go to Devices > Configuration profiles.
  • Locate the existing “Trusted certificate” profile that is linked to your SCEP profile, or create a new one.
  • Crucially, upload the new, genuine Root CA certificate to this profile. If you had previously uploaded an intermediate certificate, this is where you correct that mistake.
  • Ensure the profile is assigned to the correct user or device groups.
• Verify SCEP Profile Linkage: Double-check that your SCEP profile in Intune is correctly linked to this updated or new Trusted Certificate profile. Without this linkage, the iOS devices will not receive the necessary anchor of trust.

4. Verification and Testing¶

After implementing these changes, thorough verification is critical to confirm the resolution.

• Test Browser Access: From an iOS device, try navigating to https://<NDESurl>/?operation=GetCACaps again. You should now see an XML response indicating the NDES server’s capabilities, without any SSL errors. This confirms the device can now establish a trusted connection and query capabilities.
• Check IIS Logs: Monitor the IIS logs for GetCACaps requests originating from iOS devices. Successful entries (HTTP 200 response) should now appear.
• Monitor Device Logs: On a test iOS device, initiate a sync with Intune and observe the device console logs. You should no longer see the SecTrustEvaluate or “Registration Authority’s response is invalid” errors related to SCEP. Instead, you should see successful SCEP enrollment messages.
• Deploy to a Small Group: Before a broad rollout, deploy the updated SCEP and Trusted Certificate profiles to a small pilot group of iOS devices to ensure everything functions as expected.

Supporting Media: Signature Algorithm Compatibility¶

To further clarify the context of signature algorithms, consider the following table which highlights common algorithms and their general compatibility status in modern environments, especially for secure certificate enrollment.

Signature Algorithm	Description	Common Use	iOS/Modern OS Compatibility	Security Status
SHA-1	Secure Hash Algorithm 1, cryptographic hash function, often used with RSA.	Older PKI, legacy systems.	Deprecated/Unsupported. Modern iOS/browsers actively block or warn against certificates signed with SHA-1 for trust.	Cryptographically weak, prone to collision attacks. Should be avoided.
SHA256RSA	RSA signature algorithm with SHA-256 hash. Part of the SHA-2 family.	Current industry standard.	Fully Supported. Recommended for all new certificate deployments.	Strong, widely accepted, provides robust security.
SHA384RSA	RSA signature algorithm with SHA-384 hash.	High-security applications.	Fully Supported. Offers even stronger security than SHA256RSA.	Very strong, suitable for environments requiring higher security assurance.
SHA512RSA	RSA signature algorithm with SHA-512 hash.	High-security applications.	Fully Supported. Similar to SHA384RSA but with a larger hash output.	Very strong.
RSASSA-PSS	RSA Signature Scheme with Appendix - Probabilistic Signature Scheme.	Modern, more secure RSA.	Generally Supported by modern OS, but can sometimes have compatibility issues in specific older configurations or implementations of SCEP if not carefully managed.	Provides enhanced security and resistance to certain attacks compared to traditional RSA signatures (PKCS#1 v1.5).

Important Considerations¶

• Offline Root CA: If your Root CA is offline, ensure the new root certificate is properly imported and distributed. The security procedures around an offline CA are stringent and must be followed.
• Certificate Lifetime: When reissuing certificates, consider the remaining lifetime of dependent certificates. Short-lived certificates can minimize exposure to cryptographic obsolescence but increase administrative overhead.
• Documentation: Document all changes made to your PKI and NDES configuration meticulously. This will be invaluable for future troubleshooting and auditing.
• Communication: Communicate effectively with users about any potential impact or required device actions during the certificate update process.

Conclusion¶

Resolving Intune iOS SCEP failures characterized by missing GetCACaps requests is often a testament to the crucial role of a healthy and up-to-date PKI. By methodically identifying incorrect trusted root certificates or outdated signature algorithms, and subsequently reissuing certificates with modern, supported standards like SHA256RSA, administrators can restore robust and secure certificate enrollment for their iOS fleets. The process requires careful planning, execution across the CA, NDES, and Intune components, and thorough verification to ensure a seamless and secure environment.

Have you encountered similar SCEP failures in your environment? What specific steps or tools proved most effective in your troubleshooting journey? Share your experiences and insights in the comments below to help the community build more resilient Intune deployments.