Tag: gpo

Installing the Wavecrest Root Certificate on Client Machines for CyBlock SSL Inspection

Applies to: CyBlock (proxy SSL inspection) · Area: Settings → Proxy → SSL Inspection Where it happens: each end-user’s computer

Which certificate are you looking for? (There are three — this is #3)

They’re easy to confuse. The quick tell is whose machine the certificate goes on and what it’s for:

Console / UI certificate — installed on the server, so administrators reach the Cyfin/CyBlock admin console over validated HTTPS. See Installing Your Own SSL Certificate on the Cyfin/CyBlock Web Interface (Secure Interface).
Proxy SSL certificates (Settings → Proxy → SSL Certificates) — client-authentication certificates the CyBlock proxy uses internally during inspection. Advanced/optional; CyBlock proxy only.
Wavecrest root certificate on end-user machines — this article. Installed on every user’s computer so their browser trusts CyBlock’s inspected HTTPS connections and SSL inspection works without certificate errors.

If your users are getting certificate warnings on HTTPS sites after you turned on SSL inspection, you’re in the right place — this is #3.

Why this is required

When SSL inspection is enabled, the CyBlock proxy decrypts each user’s HTTPS connection and re-secures it using a certificate signed by the Wavecrest root certificate authority (CA). If a user’s computer doesn’t already trust that Wavecrest root, the browser treats every inspected HTTPS site as untrusted and shows a certificate warning.

Installing the Wavecrest root certificate into the machine’s Trusted Root Certification Authorities store (or the browser’s own store, for Firefox) makes those inspected connections validate cleanly — no warnings. This is why the manual lists “Install the Wavecrest Certificate” as a required step, and why it must be done on each client whose traffic you inspect.

Do this before you enable SSL inspection, so users never see the warning in the first place.

Step 1 — Download the Wavecrest certificate

The certificate is served by your CyBlock instance, so always get it from the in-product link rather than a hard-coded address:

In CyBlock, go to Settings → Proxy → SSL Inspection.
Click the “Click here to install the Wavecrest Certificate” link on that screen. It points to your instance’s certificate file (for cloud customers this is your region’s host; for on-prem/VM it’s your own CyBlock server).
Save the certificate file — nokeywavecrest.crt — somewhere you can reach it during install. You’ll distribute this same file to client machines.

If you can’t locate the link, Wavecrest Technical Support can provide it: support@wavecrest.net or (321) 953-5351, Ext. 4.

Step 2 — Install the certificate on client machines

Pick the method that matches how your users’ machines are managed. For a domain environment, the Active Directory / GPO method (below) installs to all machines at once and is the recommended approach.

Windows 10 / 11 — single machine (manual)

Copy nokeywavecrest.crt to the machine and double-click it, then click Install Certificate.
Choose Local Machine (installs for all users on that PC; requires admin) and click Next.
Select Place all certificates in the following store, click Browse, choose Trusted Root Certification Authorities, and click OK → Next → Finish.
Click Yes on the security warning to confirm the root install.

Google Chrome and Microsoft Edge on Windows use this system store, so no separate steps are needed for them. (Firefox is separate — see below.)

Windows — all domain machines via Active Directory (GPO)

On the domain controller, open Group Policy Management.
Edit the GPO you use for client machines (for example, Default Domain Policy).
Navigate to Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities.
Right-click it, choose All Tasks → Import, and complete the wizard, selecting nokeywavecrest.crt and the Trusted Root Certification Authorities store.
Client machines pick up the certificate on their next Group Policy refresh.

macOS — single machine (Keychain Access)

Copy nokeywavecrest.crt to the Mac and double-click it to open Keychain Access.
Add it to the System keychain (requires an admin login) so it applies to all users.
In Keychain Access, find the Wavecrest certificate, double-click it, expand Trust, and set When using this certificate to Always Trust. Close the window and authenticate to save.

Safari and Chrome on macOS use the system keychain; Firefox does not (see below).

Firefox — any operating system (its own certificate store)

Firefox does not use the OS store, so it needs the certificate imported separately on each machine (or distributed via Firefox enterprise policy):

Open Firefox → Settings → Privacy & Security → Certificates → View Certificates.
On the Authorities tab, click Import and select nokeywavecrest.crt.
Check Trust this CA to identify websites, click OK, and close the dialog.

Step 3 — Verify

On a client where you installed the certificate, browse to an HTTPS site in a category you’ve set to Inspected.
Confirm the page loads with the padlock and no certificate warning.
(Optional) View the certificate details — the issuer chain should show Wavecrest as the signing authority, confirming the inspected connection is trusted.

Inspected traffic can then be viewed in the Real-Time Web Monitor and in audit reports.

Important notes

Install before enabling inspection. Turning on SSL inspection before the root certificate is on client machines is the most common cause of “certificate error on every site” reports.
Some applications may still error. Apps that don’t use the operating system’s certificate store (they ship their own trust list or use certificate pinning) can fail under SSL inspection even after the root is installed. If you hit this, contact Wavecrest Technical Support at support@wavecrest.net or (321) 953-5351, Ext. 4.
This is a per-client step. Every machine whose HTTPS traffic you inspect needs the root certificate. GPO (Windows) and Firefox enterprise policy scale this to many machines at once.
Not the console/interface certificate. Installing your own certificate to reach the CyBlock admin UI over HTTPS is a different task — see the Secure Interface article.

CyBlock — Users Not Being Identified (Missing User IDs / Browser Login Prompt)

Applies to: CyBlock · When activity isn’t logged by username, or employees get browser login prompts.

CyBlock identifies users automatically via NTLM as their traffic passes through the proxy. When that identification fails, you’ll see one or both of these symptoms:

Usernames are blank or show as IP addresses in CyBlock activity and reports.
Employees get a pop-up username/password prompt in Edge or Chrome when browsing — even to everyday sites.

Both symptoms mean CyBlock isn’t successfully identifying the user. Work through the two areas below in order: first confirm CyBlock’s own authentication rule, then (if users are being prompted) the Windows/browser configuration.

(If usernames are appearing but all fall under Ungrouped IDs, that’s a different issue — IDs are captured but not organized into your Groups and IDs tree. See the Terms Glossary for Ungrouped IDs.)

Step 1 — Check the CyBlock Authentication Manager rule

Start here. CyBlock needs an NTLM authentication rule to identify users.

Go to User Management → Authentication → Authentication Manager.
Open the Rules tab.
Confirm there is a rule with:
- Type: NTLM, and
- Network definition: *Default

If that NTLM rule is present and correct, CyBlock is set up to identify users, and the problem is most likely on the Windows/browser side — continue to Step 2. If the rule is missing or its network definition is wrong, correcting it here is the fix.

Step 2 — If employees are being prompted to log in (Windows/browser configuration)

What’s happening and why

CyBlock identifies users silently by asking the browser to confirm the employee’s Windows login as traffic passes through the proxy — normally invisible to the user. Recent Windows 11 and Edge/Chrome security changes tightened the rules around this automatic sign-in, so the browser now needs to be explicitly told it’s safe to release Windows credentials to the CyBlock proxy. If it isn’t, the browser either prompts the employee for credentials or skips identification entirely (leaving usernames blank).

This is a Microsoft security change, not a CyBlock defect. The fix is applied by your IT administrator via Group Policy (GPO), which pushes the settings to all computers at once. Getting cloud-proxy NTLM working reliably requires two GPO controls — both must be in place.

Which browsers need configuration

Microsoft Edge — requires configuration
Google Chrome — requires configuration
Internet Explorer — not affected
Firefox — uses a separate process; contact Wavecrest Support if Firefox is in use

Layer 1 — Allow the proxy to request Windows authentication (AuthServerAllowlist)

This tells Edge and Chrome that the CyBlock proxy is allowed to request integrated Windows authentication.

Microsoft Edge (GPO):

Open Group Policy Management Console (gpmc.msc) and edit a GPO linked to the OU containing your computers.
Go to Computer Configuration → Administrative Templates → Microsoft Edge → HTTP authentication.
Open Configure list of allowed authentication servers, set it to Enabled.
In the value field, enter: *.cloud.cyblock.com,cloud.cyblock.com
Click OK.

(First-time setup: download the Edge policy templates from https://www.microsoft.com/en-us/edge/business/download and copy msedge.admx / msedge.adml into your domain controller’s Central Store.)

Google Chrome (GPO):

In the same or a linked GPO, go to Computer Configuration → Administrative Templates → Google → Google Chrome → HTTP authentication.
Open Authentication server allowlist, set it to Enabled.
In the value field, enter: *.cloud.cyblock.com,cloud.cyblock.com
Click OK.

(Registry equivalent, for non-domain machines — apply as a computer/HKLM policy:

Edge: HKLM\SOFTWARE\Policies\Microsoft\Edge → AuthServerAllowlist (REG_SZ) = *.cloud.cyblock.com,cloud.cyblock.com
Chrome: HKLM\SOFTWARE\Policies\Google\Chrome → AuthServerAllowlist (REG_SZ) = *.cloud.cyblock.com,cloud.cyblock.com)

Layer 2 — Move the proxy into the Local Intranet zone (Site to Zone Assignment)

Even with Layer 1 set, Windows checks the security zone of the proxy host before it will release credentials automatically. Because cloud.cyblock.com is an internet-hosted address, Windows treats it as the Internet zone, and Internet-zone hosts prompt the user instead of signing in silently. The proxy must be reassigned to the Local Intranet zone for automatic authentication to work.

GPO:

Go to Computer Configuration → Policies → Administrative Templates → Windows Components → Internet Explorer → Internet Control Panel → Security Page → Site to Zone Assignment List.
Set it to Enabled, then click Show and add:
- Value name: cloud.cyblock.com
- Value: 1 (1 = Local Intranet zone)
Click OK.

(Even though the GPO path says “Internet Explorer,” this zone list is also read by Edge and Chrome for the integrated Windows authentication credential decision.)

(On-premise / appliance deployments: substitute your own internal proxy hostname for cloud.cyblock.com. Whether the zone step is needed depends on whether your proxy hostname already resolves to the Local Intranet zone — contact Wavecrest Support if unsure.)

Single-machine test (before a full GPO rollout)

To confirm the two-layer fix on one affected machine before deploying via GPO, run these as Administrator, then fully restart the browser and check the CyBlock log for usernames:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\cloud.cyblock.com" /v https /t REG_DWORD /d 1 /f

reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v AuthServerAllowlist /t REG_SZ /d "*.cloud.cyblock.com,cloud.cyblock.com" /f

Apply and verify

Run gpupdate /force on a test machine (or wait for Group Policy to refresh).
Fully restart the browser — these policies require a complete browser restart, not just a new tab.
Confirm the policy is active: open edge://policy (Edge) or chrome://policy (Chrome) and check that AuthServerAllowlist shows the correct value.
Browse to any external site, then check the CyBlock activity log for the username.
If it’s still not working, check Event Viewer → Applications and Services Logs → Microsoft → Windows → GroupPolicy for GPO application errors.

Troubleshooting

Symptom	Likely cause	Action
Usernames blank, no NTLM rule found	CyBlock auth rule missing	Add/correct the NTLM rule (`*Default`) in Authentication Manager (Step 1)
Login prompts persist after GPO deployed	Browser not fully restarted	Close and reopen all browser windows
Usernames still blank after Layer 1	Proxy still in Internet zone	Apply the Layer 2 Site-to-Zone assignment
Policy not showing in `edge://policy`	Edge ADMX templates not installed	Install templates in the Central Store on your domain controller
Only some computers affected	GPO linked to wrong OU	Ensure the GPO is linked to the OU with computer accounts, not user accounts

Additional notes

Apply these as computer policies (HKEY_LOCAL_MACHINE), not user policies.
Multiple proxy addresses can be listed, comma-separated, no spaces.
This is part of Microsoft’s ongoing phase-out of older authentication methods; Wavecrest will update guidance as the rollout continues.
For help, contact support@wavecrest.net.