When implementing RADIUS authentication with PEAP-MSCHAPv2 on Windows Server 2012 R2, I encountered a peculiar scenario where GoDaddy's SAN certificate was trusted by Android and Windows clients but rejected by iOS devices (specifically iPhone 6s/6s Plus running iOS 10). The devices displayed "Not verified" warnings despite GoDaddy being a trusted root CA.
First, verify your certificate chain is properly installed on the NPS server. Run this PowerShell command to check:
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Subject -match "your-cert-subject" } | Select-Object -Property Subject, NotAfter, Thumbprint, SerialNumber
Then examine the chain:
$cert = Get-ChildItem -Path Cert:\LocalMachine\My\THUMBPRINT_HERE $chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain $chain.Build($cert) $chain.ChainElements | Select-Object -Property Certificate
iOS devices are particularly strict about intermediate certificates. GoDaddy's root may be trusted, but if any intermediate certs are missing in the chain, iOS will reject it. Check your NPS server's certificate store contains:
- Your server certificate (in Personal store)
- GoDaddy intermediate certificates (in Intermediate Certification Authorities store)
- Root certificate (in Trusted Root Certification Authorities store)
When exporting your certificate for NPS, include all certificates in the chain:
certutil -exportPFX -p "password" My LocalMachine CERT_THUMBPRINT fullchain.pfx
Then reimport to NPS:
Import-PfxCertificate -FilePath C:\path\to\fullchain.pfx -CertStoreLocation Cert:\LocalMachine\My -Password (ConvertTo-SecureString -String "password" -AsPlainText -Force)
If chain issues persist, consider implementing certificate pinning in your Wi-Fi configuration profile (for MDM deployment):
<dict> <key>PayloadContent</key> <array> <dict> <key>EAPClientConfiguration</key> <dict> <key>AcceptEAPTypes</key> <array> <integer>25</integer> <!-- PEAP --> </array> <key>TLSTrustedServerNames</key> <array> <string>your-server-name.com</string> </array> <key>TTLSInnerAuthentication</key> <string>MSCHAPv2</string> </dict> <key>PayloadCertificateAnchorUUID</key> <array> <string>YOUR_CERT_UUID</string> </array> </dict> </array> </dict>
To confirm which GoDaddy roots iOS 10 trusts, check Apple's documentation or run this test on an iOS device:
- Connect to your Wi-Fi network
- When prompted, view the certificate details
- Check which root CA it traces back to
- Compare with Apple's trusted root list
- All intermediate certificates installed
- Certificate has proper SAN entries (including RADIUS server FQDN)
- NPS service restarted after certificate changes
- Tested with updated root certificates on iOS devices
When implementing RADIUS authentication with Windows Server 2012 R2 NPS using PEAP-MSCHAPv2, we're seeing inconsistent certificate validation across platforms:
Platform | Trust Status
----------------|-------------
Windows 10 | Trusted
Android 8+ | Trusted
iOS 10+ | Untrusted (manual override required)
The issue stems from iOS's stricter certificate chain validation. GoDaddy certificates require proper intermediate CA installation that iOS enforces more rigorously than other platforms. The server isn't sending the complete certificate chain during TLS negotiation.
To verify the chain completeness, run this OpenSSL command against your RADIUS server:
openssl s_client -connect radius.yourdomain.com:1812 -showcerts
On your NPS server, ensure the certificate chain is properly installed:
- Open MMC → Add Certificates snap-in (Computer account)
- Import all intermediate certificates to "Intermediate Certification Authorities"
- In NPS configuration, rebind the certificate
For automated deployment, use this PowerShell script:
# Import GoDaddy intermediate certificates
$intermediateCert = Get-ChildItem -Path "C:\certs\gd_intermediate.crt"
Import-Certificate -FilePath $intermediateCert.FullName -CertStoreLocation Cert:\LocalMachine\CA
# Restart NPS service
Restart-Service -Name "IAS" -Force
For immediate relief while fixing the server configuration:
Option 1: Deploy mobileconfig profile for iOS devices:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>PayloadType</key>
<string>com.apple.security.root</string>
<key>PayloadCertificateFileName</key>
<string>GodaddyRoot.crt</string>
<key>PayloadContent</key>
<data>BASE64_ENCODED_CERT_HERE</data>
</dict>
</array>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>
To prevent such issues:
- Always include the full chain when installing server certificates
- Use SSL Labs' test tool to verify chain completeness
- Consider using certificates from providers with better mobile OS support (DigiCert, Sectigo)
- Regularly update root CA stores on all client devices