FortiGate Application Filter Certificate wrong/missing Entry sample for an important laptop driver (W10 Deployment fails because of signed Driver Revocation Lookup)
Missing entry in Fortigate Application Filter “ROOT.CERTIFICATE.URL” and “OCSP” source of failing
Windows 10 Deployment with commercial Deployment Products (This includes HP client hardware, Microsoft SCCM, Landesk or Ivanti Frontrange).
During the Unattend phase the driver for MASS storage or NIC does a Certificate Revocation Lookup. However the as sample mentioned
URL pki.infineon.com (Hardware Driver URL, CRL FQDN) is missing in Fortiguard definitions. Thus the Fortigate does block the access to WAN. Since this is an early setup phase of W10, group Policy or special GPO do not pull at that moment.
Fortigate has already missed several PKI URL the last few months confirmed by ticket resulting in large trouble and delay on client and Server OS of customers who route their Client or Server traffic
through Web proxy and because of security do not want to route computer account proxy traffic standard to the proxy.
Why this is so important. Why this is generating a lot of work and trouble for OS-Deployment teams.
The normal way in larger companies is that all outgoing traffic from client VLAN goes to Firewall which it blocks. All Web/Application/Socks traffic that should go outside goes to a Proxy, Web filter.
Because in early phase of Deployment those options are not set already and normally not needed. However if the driver is older than the Expiration of the Code Signing Certificate W7/W100 will check
The Certificate Revocation list from WAN/Internet. If that fails it may refuse to integrate the driver in Windows PE or early Windows Setup phase. If example this is a driver which
Handels NIC (network) or mass Storage driver (Disk) they deployment can’t run through this early process.
Workaround:
URL we need open in our sample: pki.infineon.com which prevents a complete Enterprise Deployment system to fail
Sample from Fortigate for other Certs they missed:
F-SBID( –name “Root.Certificate.URL_Custom”; –protocol tcp; –app_cat 17; –service HTTP; –flow from_client; –pcre “/(crl\.microsoft\.com|\.omniroot\.com|\.verisign\.com|\.symcb\.com|\.symcd\.com|\.verisign\.ne t|\.geotrust\.com|\.entrust\.net|\.public- trust\.com|\.globalsign\.|\.digicert\.com|crl\.startcom\.|crl\.cnnic\.cn|crl\.identrust\.com|crl\.thaw te\.com|crlsl\.wosign\.com|www\.d\-trust\.net)/”; –context host; –weight 15; )
In our case:
F-SBID( –name “Root.Certificate.pki.infineon.com”; –protocol tcp; –app_cat 17; –service HTTP; — flow from_client; –pcre “/(pki\.infineon\.com)/”; –context host; –weight 15; )
If you have such problems please try our free tool crlcheck.exe
CRL check, Zertifikatsperrlisten Software, Certificate Revocation List Check Tool zum suchen aller geblockten CRL in Firmenumgebungen, crlcheck.exe
CRLcheck.exe Certificate Revocation List Check Tool to verify all CRL and OCSP on Windows client