Resolving Web Login Issues with
the Forcepoint Security Manager
Forcepoint Web Security uses
certificate files to encrypt
inter-service communication.
Issues can arise when the components on the
Windows Server are unable to successfully
communicate to other Web Security services.
When this happens, end-users continue
to be filtered correctly,
but it impacts logging into the Web tab
on the Forcepoint Web Security Manager.
This will prevent administrators from
updating their Web policies.
This issue can manifest itself
in different ways with the following error variations:
Forcepoint Web Security could not be launched,
HTTP 500 error
The website cannot display the page,
Proxy Error GET on websense.jsf
cannot connect to the base policy server.
These problems are easily identifiable,
since these errors only occur
when attempting to access the Web Security tab.
Admins find
they can typically still access other tabs
on the FSM to manage additional
Forcepoint products.
And even if they don't have active
licenses for the other products,
they can still access the Global Settings
under the gears icon. Despite the
error seen when attempting to access Web.
In this video, we will highlight various
methods customers can perform
to resolve the issue for both pre 8.5
and modern Web Security versions.
We will first explore
three different ways the issue can be addressed
for 8.4 in earlier versions.
When encountering this FSM Triton
log in issue. The first thing
to try is to recreate the .p12 certificates
by restarting services.
Launch services.msc
and stop the identified services in the
following order:
Triton Web Security,
Triton Web Server
Triton Unified Security Center
and lastly, Triton Settings Database.
Sometimes a service is hung
or encounters problems coming down cleanly.
In this case, we can kill the service
directly at the OS.
First, identify the Windows Service name
and copy it to the clipboard.
Then launch command prompt
and run the following command to find the Program ID
of the service in question.
Type sc queryex
and paste in the service name
we just copied.
Once you have the Program ID identified,
proceed to issue the following kill command:
taskkill /pid <program ID> /f
to force kill the service.
Running the Service Control Query again
will confirm the problem service is now stopped.
With the needed Triton Services stopped,
our next step is to launch Windows Explorer
and navigate to the
Websense\Web Security\tomcat\bin directory
And from here we will delete
the .p12 certificate files.
These files will be recreated
automatically when the service restarts.
Please note on older Web Security versions,
you may see a manager .p12 file,
do not delete this file.
Once the old .p12 files are
removed, start the Triton Services
in the reverse order as before.
Triton Settings Database.
Triton Unified Security Center
Triton Web Server and
finally, Triton Web Security.
Wait a minute, for the Triton Services
to settle and try logging back into the
Forcepoint Security Manager.
Clearing .p12 and restarting
the services usually resolves
this type of issue.
However, sometimes additional
steps are required to recreate
the security certificates by using
the provided automation scripts.
In Windows Explorer, navigate to the
Websense\Web Security\apache\conf\ssl\automation directory.
and Run the following batch files:
in the provided order S1 - S5.
These create new files in the
Websense\Web Security\apache\conf\ssl\output directory.
Go ahead and right click to open
this directory in a new window.
As we'll next need to copy these files
to their new destination.
First, copy server.key to the
Websense\Web Security\apache\conf\ssl\ssl.key directory
Second, copy the server.crt file to the
Websense\Web Security\apache\conf\ssl\ssl.crt directory
Then, copy the cakey.pem to the
Websense\Web Security\apache\conf\ssl\private directory.
Next, copy the manager .p12 to the
Websense\Web Security
\tomcat\conf\keystore\tomcat directory.
Afterwards, copy the cert.txt file to the
Websense\Web Security
\Manager\OnlineHelp\en\certificateSupport folder.
With the newly generated files
copied over from the SSL Output
directory, we next need to
go to the Windows Services and
restart the following services in
the specified order.
First, restart Websense Triton Web Security.
Next, restart Websense Web Reporting Tools.
Finally, restart the Websense RTM Client service.
Wait a minute, then try logging back
into Forcepoint Web Security.
Normally, the issue can be addressed
by simply regenerating the various certificate files.
As a last resort, customers
can reinstall the Web Security components.
Follow the prompts in the installer to
remove the Triton Manager (Web module )
from the Forcepoint Web Security.
After the Windows Server restarts,
run the installer again and click Modify
to reinstall the component we just removed.
We previously saw three
methods to address the Forcepoint Security
Manager Web logon issue
as it relates to the .p12 certificate files.
In the 8.5 Web Security release,
Forcepoint Engineering
updated many services to
take advantage of updated Java crypto libraries.
As a result, we're now using .bcfks files
to encrypt inter-component communication.
These files help provide stronger
FIPS compliance to the 8.5 and later deployments.
To address the FSM logon issue,
very similar procedures are followed
as discussed earlier with the 8.4 release,
but with slight variations to
account for the .bcfks certificates.
If encountering this FSM logon issue,
the first thing to try is to recreate the
.bcfks certificates by restarting services.
Launch services.msc
and stop the identified services in the following order:
Triton Web Security,
Triton Web Server,
Triton Unified Security Center
and lastly, Triton Settings Database.
With the needed Triton services stopped,
our next step is to launch Windows Explorer
and navigate to the
Websense\Web Security\tomcat\bin directory.
From here, we will delete any
.bcfks certificate files that we encounter.
These files will be recreated
automatically when the services restart.
With the old files removed,
Go back to the window services and
restart the Triton services in the
following order:
Triton Settings Database
Triton Unified Security Center
Triton Web Server
and finally, Triton Web Security.
Wait a minute for the Triton services
to settle and try logging back into the
Forcepoint Security Manager.
Sometimes having the services
recreate the certificates is
insufficient and the issue persists.
In these cases, system administrators
can run the following batch files
to manually recreate the needed
security files.
In Windows Explorer, navigate to the
Websense\Web Security\apache\conf\ssl\automation directory
and run the following batch files
in the provided order S1 - S6
these create new files in the
Websense\Web Security\apache\conf\ssl\output directory.
Go ahead and right click to open
this directory in a new window,
as we'll next need to copy these files
to their new destination.
First copy server.key to the
Websense\Web Security\apache\conf\ssl\ssl.key directory.
Second, copy the server.crt file to the
Websense\Web Security\apache\conf\ssl\ssl.crt directory.
Then, copy the cakey.pem to the
Websense\Web Security\apache\conf\ssl\private directory.
Next, copy the manager.p12 file to the
Websense\Web Security
\tomcat\conf\keystore\tomcat directory.
Afterwards, copy the cert.txt file to the
Websense\Web Security
\Manager\OnlineHelp\en\certificateSupport folder.
Lastly, copy the remaining manager.bcfks file to the
Websense\Web Security
\tomcat\conf\keystore\tomcat directory.
With the newly generated files
copied over from the SSL Output directory,
we next need
to go to the Windows Services and
restart the following services in
the specified order.
First restart Websense Triton Web Security.
Next, restart Websense Web Reporting Tools.
Finally, restart the Websense RTM Client service.
Wait a minute, then try logging back
into Forcepoint Web Security.
Typically, these problems can be addressed
by following the previous steps and regenerating the certificates.
On rare occasions, a reinstall
of the Forcepoint Web Security component
may be necessary.
Reinstalling this component creates
new certificates without having to manually
edit the files.
In this video, we showcased
the more common ways customer administrators
can resolve problems when logging into the
Forcepoint Security Manager.
This problem is typically resolved
by fixing the certificate files used
to encrypt inter-service communication
by clearing the .p12 / .bcfks files
and restarting services,
by recreating the current key files
through automation scripts,
and by reinstalling
Web Security components .
As indicated earlier, this issue
occurs when the certificate files become corrupted.
Forcepoint recommends
disabling both the User Access Control
and Data Execution Prevention features,
as well as
configuring Antivirus Scanning Exceptions
to help prevent possible
corruption to these sensitive files.
For more information regarding this error,
review the following Knowledge Base Article.
Thanks for watching!
Yeah,
