APM 17.5.1.9 certcheck (failures, exceptions)

Forums Technical Forums
,
1

Since updating to 17.5.1.9 instead of getting debug\verbose level logging in f5mcertcheck.txt . I can no longer see details of the cert mapping progress which makes trouble shooting what is happening really difficult from the client side.

Info 2026-09-08 16:10:55:649 current log level = 63

Info 2026-09-08 16:10:55:649 \CertCheck.cpp, ::DllMain, ActiveX control location: “C:\Windows\Downloaded Program Files\f5certchk.dll”

Error 2026-09-08 16:10:56:160 CCertCheckImpl::Verify FindCertificateInStore failed with error code:

Error 2026-09-08 16:10:56:160 \CertCheckImpl.cpp, CCertCheckImpl::Verify, EXCEPTION caught: CCertCheckImpl::Verify - EXCEPTION

I know it found a working cert because its letting me connect but I need visibility into what certs it checked against what policy settings. Before this update I was able to see much more info example:

Info 2026-09-02 17:46:51:362 \CertCheck.cpp, ::DllMain, ActiveX control location: “C:\Windows\Downloaded Program Files\f5certchk.dll”

Info 2026-09-02 17:46:51:873 \CertCheckImpl.cpp, CCertCheckImpl::Verify, certInfo:STORE_NAME:MY&STORE_LOCATION:LocalMachine&ALLOW_ELEVATION:0&MATCH_FQDN:0&SN:&ISSUER:CN=MY Intermediate, O=*, OU=IT, L=Anytown, S=DC, C=US&SAN:, RootCertInfo:IS_TRUSTED:0, Nonce: QUFFM2ozcFVUU1BwZTVVUFRLdUs=

Info 2026-09-02 17:46:51:873 \CertCheckImpl.cpp, CCertCheckImpl::Verify, Store name:“MY”, Store location:“LocalMachine”, Subject match FQDN:“false”, Allow elevation UI:“false”, Serial number(HEX):“”, Issuer:“CN=MY Intermediate, O=*, OU=IT, L=Anytown, S=DC, C=US”, SubjectAltName:“”

Info 2026-09-02 17:46:51:875 \certinfo.cpp, CCertInfo::FindCertificateInStoreExt:, Total certs tested: 5

Info 2026-09-02 17:46:51:875 \certinfo.cpp, CCertInfo::MatchCertificate, CN=MY Intermediate, O=Contoso, OU=IT, L=Anytown, S=DC, C=US doesn’t match pattern “CN=MY Intermediate, O=*, OU=IT, L=Anytown, S=DC, C=US”

Info 2026-09-02 17:46:51:875 \certinfo.cpp, CCertInfo::MatchCertificate, CN=Microsoft Intune Device Management Device CA doesn’t match pattern “CN=MY Intermediate, O=*, OU=IT, L=Anytown, S=DC, C=US”

Info 2026-09-02 17:46:51:875 \certinfo.cpp, CCertInfo::MatchCertificate, CN=Microsoft Intune MDM Device CA doesn’t match pattern “CN=MY Intermediate, O=*, OU=IT, L=Anytown, S=DC, C=US”

Info 2026-09-02 17:46:51:875 \certinfo.cpp, CCertInfo::MatchCertificate, CN=MS-Organization-P2P-Access [2025] doesn’t match pattern “CN=MY Intermediate, O=*, OU=IT, L=Anytown, S=DC, C=US”

Info 2026-09-02 17:46:51:875 \certinfo.cpp, CCertInfo::MatchCertificate, DC=net + DC=windows + CN=MS-Organization-Access + OU=82dbaca4-3e81-46ca-9c73-0950c1eaca97 doesn’t match pattern “CN=MY Intermediate, O=*, OU=IT, L=Anytown, S=DC, C=US”

Info 2026-09-02 17:46:51:875 \certinfo.cpp, CCertInfo::FindCertificateInStoreExt:, Didn’t find matched certificate

Info 2026-09-02 17:46:52:593 \CertCheckImpl.cpp, CCertCheckImpl::Verify, certInfo:STORE_NAME:MY&STORE_LOCATION:LocalMachine&ALLOW_ELEVATION:1&MATCH_FQDN:0&SN:&ISSUER:CN=MY Intermediate, O=Contoso, OU=IT, L=Anytown, S=DC, C=US&SAN:, RootCertInfo:IS_TRUSTED:0, Nonce: VkdCRko1WGJoYWVycmgxaDh1TDc=

Info 2026-09-02 17:46:52:593 \CertCheckImpl.cpp, CCertCheckImpl::Verify, Store name:“MY”, Store location:“LocalMachine”, Subject match FQDN:“false”, Allow elevation UI:“true”, Serial number(HEX):“”, Issuer:“CN=MY Intermediate, O=Contoso, OU=IT, L=Anytown, S=DC, C=US”, SubjectAltName:“”

Info 2026-09-02 17:46:52:596 \certinfo.cpp, CCertInfo::MatchCertificate, CN=MY Intermediate, O=Contoso, OU=IT, L=Anytown, S=DC, C=US matches pattern CN=MY Intermediate, O=Contoso, OU=IT, L=Anytown, S=DC, C=US(extracted content=“”)

Info 2026-09-02 17:46:52:596 \certinfo.cpp, CCertInfo::FindCertificateInStoreExt:, Total certs tested: 1

Info 2026-09-02 17:46:52:596 \certinfo.cpp, CCertInfo::FindCertificateInStoreExt:, Found matched certificate

2

Hi nicholse

I checked the information that you put in the post and I belive that f5mcertcheck.txt is generated by the Client/Machine Cert Inspection component (f5certchk.dll), documented in F5 K000150897 and K00819308. Your log already shows current log level = 63 (max local verbosity), so this isn’t a client-side logging config gap on your end.

I believe the real cause is a documented behavior change introduced in APM Client (Edge Client) 7.2.7, not a bug. From the official 7.2.7 release notes (“Features and enhancements” → Custom Logging Preferences for Windows Edge Client):

“You can select the required log level from APM Client Log Level drop-down in General Settings while creating a connectivity profile from Access > Connectivity/VPN > Connectivity > Profiles in BIG-IP. By default, it is set to Info. Note: If the BIG-IP Server log level is set to ERROR, WARN, or INFO, it will override the Client Log Level. The APM Client Log Level is considered only when the BIG-IP Server log level is set to DEBUG or TRACE. If they differ, the lower log level (less verbose) is applied. […] This feature requires BIG-IP version 21.1 or later.”

In other words, starting with Edge Client 7.2.7, the effective logging level written to disk is the lower (less verbose) of the client’s local level and a server-side log level — and the UI to raise that server-side level to DEBUG/TRACE (Access > Connectivity/VPN > Connectivity > Profiles > General Settings > APM Client Log Level) only exists on BIG-IP 21.1+. Since you’re on 17.5.1.9, that knob isn’t available, so the per-certificate match trace (certinfo.cpp :: MatchCertificate, FindCertificateInStoreExt: Total certs tested, etc. — all Debug/Trace-level lines) gets suppressed even though your local client still reports level 63.

A few things worth checking/trying:

  1. Confirm the Edge Client build on the affected endpoint (Help/About, or Programs and Features) — if it’s 7.2.7 or 7.2.7.1, that lines up exactly with when this changed (those are also the client versions currently listed as compatible with 17.5.1.x).
  2. The same release note calls out a client-side override for exactly this situation: “the MachineLogLevel must be manually created in the Registry Editor if detailed debug-level logging is required on the client side.” Try creating MachineLogLevel (string/DWORD) under HKLM\Software\F5 Networks\RemoteAccess set to DEBUG and re-test — it’s documented as the way to force detailed debug logging locally regardless of the server-side gate, though I haven’t been able to confirm whether it restores the certcheck match-loop trace specifically or only the Machine Tunnel logging.
  3. As a data point, rolling back to a pre-7.2.7 Edge Client build (e.g., 7.2.6.x) on a test machine should restore the old always-verbose behavior, which would confirm the client version (not the BIG-IP TMOS version) is what’s actually gating this.
  4. I didn’t find any Known Issue for BIG-IP 17.5.1.9 or Edge Client 7.2.7/7.2.7.1 that documents this as a defect — it reads as an (undocumented-for-older-TMOS) side effect of the new logging feature rather than a regression bug. Since auth is still succeeding, there’s no functional/security impact, just reduced local diagnostic visibility.

If the registry override in #2 doesn’t restore the detail you need, I’d open a case with F5 Support referencing this release note directly and ask whether there’s any way to get server-side DEBUG/TRACE log-level behavior on pre-21.1 BIG-IP, since the Connectivity Profile control for it appears to be 21.1+ only.

Link

3

Thanks,

Edge client is 7241,2023,331,1108 . f5certchk.dll is 7272.2026.0811.1912
I was able to revert to this edge version by removing the one that apm force updated me to and then prevent updates by editing the various f5c files to  <UPDATE><MODE>NO</MODE></UPDATE> and I set the F5 Networks Component Installer service to stopped and disabled. HKEY_CURRENT_USER\Software\F5 Networks\RemoteAccess\Logging and HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\F5 Networks\RemoteAccess\Logging dword LogLevel is set to decimal 63

I assume those are the correct keys you refer to above, I dont see any official f5 kb’s on this, just some random forum post and as you noticed, even without those keys, the client already said we were at 63.

In the above configuration, the client is still minimal cert logs. Since the f5certchk.dll is “downloaded” aka component added during connection, I wonder if the server is pushing a newer version that has limited logging. Anyhow, Ill ask the APM admin to see what additional logging options might be available in the policy.

4

Hi nicholse

Great find — that confirms it, and it’s actually documented F5 behavior, not something your local workaround could have prevented.

Per two official F5 KBs:

“Similar to browsers, components like Windows ActiveX, Host Control, InspectionHost, Machine Certificate Checker, and SuperHost, are updated automatically regardless of the Component Update setting.” —

K81649656: Overview of APM Clients update on BIG-IP APM

“Even if the Component Update setting in the Connectivity profile is set to No, some components, including Windows ActiveX components such as Host Control, InspectionHost, Machine Certificate Checker, and SuperHost, are updated automatically.”

K15302: Understanding BIG-IP Edge Client Component Update behavior

And K14045 (BIG-IP Edge Client components for Windows) confirms “Machine Certificate Checker” is the official name for the f5certchk.dll component. So this ActiveX control is hard-refreshed from whatever APM Clients package is active on the BIG-IP itself on every connection — independent of your locally installed Edge Client version, the f5c UPDATE/MODE setting, and even the server-side “Component Update” toggle. That’s exactly why reverting the main Edge Client to 7.2.4.1 didn’t help: f5certchk.dll 7.2.7.2 keeps getting pushed down regardless.

One correction to my earlier suggestion: the MachineLogLevel registry value from the 7.2.7 release note appears to be scoped to the Machine Tunnel Service, not the Machine Certificate Checker/CertCheck component — that’s likely why you couldn’t find it in any official KB (only forum posts), and it probably wouldn’t have restored the certcheck trace even if set.

So the useful question for your APM admin is: what APM Clients version is currently active under System > Software Management > APM Clients on the BIG-IP (I’d expect it to show 7.2.7.x, matching your DLL). Per K81649656, downgrading that package isn’t supported, and per the 7.2.7 release notes, the only documented way to force DEBUG/TRACE-level client logging back under the new gating scheme is the Connectivity Profile → General Settings → “APM Client Log Level” control — which requires BIG-IP 21.1+. On 17.5.1.9 that control doesn’t exist, so there doesn’t appear to be a supported path to restore this level of local diagnostic detail short of upgrading BIG-IP.

Worth raising with F5 Support as a documented product gap: pre-7.2.7 clients always gave this level of local visibility regardless of BIG-IP version; post-7.2.7, it’s tied to a BIG-IP 21.1+ feature with no fallback for earlier TMOS versions.