Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
melcu
Collaborator
Collaborator

SSLVPN Issues R82

Hi Mates,

I'm dealing witih some strange behavior. Let me explain:

Customer has a Maestro Security Group that is running one VS with MAB enabled (for SSL VPN).  They are authenticating every user with personal certificates issued by public authorities. Initially the cluster was running R81.10 so being old the customer eventually upgraded to R82 Take 91.

Since then, there's one authority that is no longer working affecting 'bout 400 users.  Workaround 🙂 generated internal certificates and everyone's happy. For the moment!

Upon cvpnd debug (and lol, it's same error in SmartConsole but I though that I will find diamonds there) the error that haunts me is:

 

[5455][28 May 19:34:50][AUTHNMAN] [CVPN_ERROR] Cvpn::AuthnManager::renegotiateCb: res=(0) - there was an error during renegotiation.
[5455][28 May 19:34:50][AUTHNMAN] [CVPN_INFO] Cvpn::AuthnManager::renegotiateCb: Certificate is not revoked
[5455][28 May 19:34:50][AUTHNMAN] [CVPN_WARNING] Cvpn::AuthnManager::doFailedOnRenegotiateError: Renegotiation failed. Error message: 'SSL renegotiation failed with error: 'Failed to fetch OCSP. Make sure the security gateway has an outgoing http access, and that the proxy and DNS servers are well configured.''

 

I have tried everything!  Gateway has full internet access, it can reach the certificate's decalred OCSP server. I have even tried to force CRL. I have replicated the environment in my homelab and I have basically the same configuration (with different public facing IP address) and even installed  R82 Take 113 as there was PRJ-65538 that caught my eye.

 

Case opened - India TAC - allow me to say useless as the engineer was looking at the portal's certificate and said it's not the same as customer's certificate 😞

 

I literally have no idea what the hell happened from R81.10 to R82 but "Failed to fetch OCSP" is driving me crazy.

Any ideas will really be appreciated. 
Thanks 

0 Kudos
5 Replies
PhoneBoy
Admin
Admin

Have you confirmed the URL in the Certificate Authority key is reachable from the gateway with curl_cli?

0 Kudos
Lesley
MVP Gold
MVP Gold

Do you use a proxy or is there a proxy in the path of the firewall? Can you access with curl from vs0 and from the relevant vs? They both need internet access. g_tcpdump would help if you pull the OSCP server from the certificate and capture on that while you see the error. It should be port 80 with Wireshark you can see if something happens. What was the result of the home lab? 

-------
Please press "Accept as Solution" if my post solved it 🙂
0 Kudos
melcu
Collaborator
Collaborator

Hi gents,
Yes  both vs0 and vs1  can reach the OCSP Server (checked by curl_cli -v ). 
There's no proxy between, the gateway has direct internet access.

Homelab as well, same issue with this authority. 

0 Kudos
Lesley
MVP Gold
MVP Gold

make wireshark capture and look for any hints like: HTTP response is "200 OK", and the OCSP response is "Successful"

Scan the website with SSL labs that uses the certificate for any hints. 

Is it maybe an ancient certificate with low encryption methods? 

Have you updated the CA list on the fw?  https://support.checkpoint.com/results/sk/sk64521

Make 100% sure there is no proxy. OSCP checks will NOT work via proxy https://support.checkpoint.com/results/sk/sk121432

 

-------
Please press "Accept as Solution" if my post solved it 🙂
0 Kudos
melcu
Collaborator
Collaborator

Yes sir! Followed all possible SKs. There is no proxy in between, as there are other 30+ authorities that are working fine. And again, this was working fine until R82 upgrade.


0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events