Usercheck Block Page is Insecure/Private

[Nikhil_Deshmukh]

• Application Control & URL filtering is enabled
• HTTPS Inspection is also enabled. Outbound Certificate is deployed in the organization and No SSL error, thanks to that. Can see HTTPS outbound certificate on browsing Internet.
• When trying to access a blocked http://website_A, block page appears.

• When trying to access a blocked https://website_A, Connection is insecure / private message appears and when selected to proceed Block page appears. Certificate on the block page is not same as HTTPS Outbound certificate. Extracted the certificate from browser and installed the same. Still at every other blocked https://website_X , connection is not secure prompt is shown before proceeding manual to block page

Customer is getting the Connection is not secure prompt before usercheck block page. Customer is quite cautious towards compliance and even the HTTPS Inspection Outbound certificate has been created with sha 256 algo.

As per customer HTTPS Usercheck Block page is not compliant as per there organization policy because it gives prompt for page being not secure

how to solve the same?

Dameon Welch Abernathy‌ help here

[PhoneBoy]

You have to configure the certificate used for Usercheck.

See my comment here:

https://community.checkpoint.com/thread/7984-usercheck-portal-certificate-problem-when-fws-ip-addres... 

[Nikhil_Deshmukh]

Agreed to the thread shared.

I also did generate the certificate through openssl, with DN name to match the IP address; as with cluster hostname it was giving me prompt that you'll face ssl error.

In the end it still doesn't work with the imported certificate for usercheck.

My obervations:-

• When trying to access a blocked https://website_A, Connection is insecure / private message appears and when selected to proceed Block page appears. Certificate is the one i created through open ssl and imported in Cluster

• Also at every other blocked https://website_x, connection is not secure appears before proceeding manual to block page

I tried this before, will give it another shot.

Also would you recommend using SHA256 certificates; and Cluster performance cautions i should take?

[PhoneBoy]

If the CA that signed that certificate isn't trusted by the browser, you'll still get the error.

That's the issue you need to fix

There's nothing wrong with using SHA256--no specific precautions are required that I am aware of.

[Nikhil_Deshmukh]

I'm generating 2 certificate's through openssl (SHA256), one for HTTPS Inspection and other for Usercheck block page.

HTTPS inspection works fine but the Usercheck Block page doesn't work as expected.

As said earlier, My obervations:-

• When trying to access a blocked https://website_A, Connection is insecure / private message appears and when selected to proceed Block page appears. Certificate shown on Block page is the one i created through open ssl for Usercheck Block Page

• Then at every other blocked https://website_x, connection is not secure appears before proceeding manual to block page

"If the CA that signed that certificate isn't trusted by the browser, you'll still get the error.

That's the issue you need to fix "

Have made both certificates CA as "Trusted Root Certification Authorities". Still getting ssl error for Usercheck Block Page 

I did all this before, will give it another shot.

[PhoneBoy]

How did you generate the certificate for UserCheck with OpenSSL? 

• If you generated it as a self-signed certificate (which is what I suspect), then the browser must be configured to accept this self-signed certificate as valid. You follow the same steps you followed to get your organization to trust the HTTPS Inspection certificate. You can validate this on your own PC by clicking on the "Install Certificate" button as shown in your screenshot.
• If you signed the certificate with a certificate authority the browser already trusts, then no configuration should be required.

[Vladimir · Accepted solution]

Please check if the UserCheck URL is changed to https. By default, it is http:

Additionally, make sure that once the https is enabled, the Root CA issuing the certificate is added to your clients' Trusted Root CAs IN ADDITION to the actual certificate for that of the UserCheck portal.

Otherwise, validation of the Issuing CA's certificate will fail.

You may find this of interest or help:

…possible reason you are keep getting the “untrusted” messages in the browsers is due to your CheckPoint Management Server’s certificate not being included in the Trusted Root CAs.

"This portal using an auto-generated  certificate. You can import your own certificate" is actually referring to the VPN cert.

When browser sees the VPN cert, it is trying to verify who has issued it and if it can trust the issuer.

The VPN cert is issued not by the gateway, but by the Management Server.

For you not to see warnings for UserCheck and VPN, three certificates must be installed in each computer’s Trusted Root CAs:

1. SSL/HTTPS Inspection certificate
2. Cluster’s VPN certificate
3. Management Server’s Root CA certificate

See the screenshots below:

1. Working VPN Cert:

 

 2. Exporting VPN Cert using Chrome

 

 3., 4.  Exporting VPN Cert Using Chrome continues

  

5. Saving VPN Cert

 

6. Navigating up the Certification path (In “General” tab, we are still looking at the VPN Certificate, but in Certification Path, we are moving to the Root)

 

7., 8. Root CA Certification export continues

 

9., 10.  Root CA Certification export continues

 

 11. Saving CheckPoint Management Root CA

 

12. All three certificates must be present in Trusted Root CAs on every computer to avoid certificate warnings with UserCheck and VPN.

 

Cheers,

Vladimir

[Nikhil_Deshmukh]

Thanks Vladimir Yakovlev‌ & Dameon Welch Abernathy‌.

Such detailed explanation, it becomes really helpful to everyone.

The certificate issued by the Management to the Gateway (Server Certificate) also contains IP address as a Alternate Subject Name.

I was able to drill down the issue with our Customer regarding this.

Customer changed the Gateway Cluster Object's IP address which changed the Platform & Usercheck Portal's Main URL.

Browser's opened Block Page on the new URL and the certificate didn't match the URL w.r.t. Alternate Subject Name.

Hence the error ERR_CERT_COMMON_NAME_INVALID (Chrome)

We can renew the certificate and update other interface IP also (if required)

Once certificate was renewed and published to user's, No error prompt in browser's faced by user's.

Note:- When creating a Certificate from Organizational Internal CA then also it important to mention the Subject Alternate Name.

Sorry for such late reply

Additional Reference :- UserCheck redirects to HTTPS even when UserCheck Portal is configured as HTTP

[Vladimir]

Speaking of late replies:)

Just run into this thread with similar situation: UserCheck portal has different IP address from main portal. Thanks to your reply I was able to re-issue the cert with second IP in SAN to solve the issue.

Cheers,

Vladimir

[Sandra_Suarez]

Hello

I have the question, maybe you can help me

My client deploys the Captive Portal for PCs external to those of the organization in a wireless network, there is some way to download and install the certificate automatically when trying to connect to the captive portal?

[David_David]

Hello,

I was able to do it, but i searched a bit before finding it

From Windows, certificate authority and generate a dedicated WebServer template.

-> That can be exportable with Private key

-> One that i can change the "Issued To"

-> I've then made a request via MMC -> Local Computer

And it works in a domain environment.

Everybody if is trusting the domain (which is normal by default in Windows domain as it was issued by the domain CA)  will work like a charm

Kind regards,

David.D

[Vladimir]

Few years later, but anyway, in case anyone is looking for solution:

The short answer, if the users are external to your organization and the certificate is self-signed is a no.

What you are asking is to install an unsanctioned by user untrusted CA.

To make this work properly, generate CRL for publicly trusted CA, get the paid certificate and import it in Portal Access Settings for Browser-Based Authentication.

Use this for references on how to create CSR:

How to generate the Wildcard certificate (SAN) CSR for Multi-Portal sk170395

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...