URL Filtering Override SSL Certificate

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

URL Filtering Override SSL Certificate

L4 Transporter

I've been experimenting with the URL override feature.  Works fine, however even with the PANs self-signed certs in the PC's trusted root authorities store, I can't seem to get away from getting a "mismatch" warning because when someone goes to www.overridesite.com the SSL cert is only valid for pan.ourdomain.com even if it trusts the CA.

Is this just how it is or is there anything I can do to make it a bit more seamless please?

Thanks in advance.

1 accepted solution

Accepted Solutions

Doesn't the URL Override redirect feature resolve this issue?  If you redirect to an interface IP or a DN that maps to an interface IP on the firewall and ensure that you're presenting an internally valid certificate, then the users shouldn't get any certificate errors.

Just got this working in my test environment a couple of days ago mysefl (running 3.1.4).  If I remember correctly, generate the cert 1st in the SSL VPN area of the certificates left hand link on the Device tab.  Once a cert has been applied, then go to the Setup left hand link of the Device tab and there should be a URL Override area on that page.  If you edit that area, you should be able to configure the specifics of the Override feature, including the Override type (redirect/transparent).  Set it to redirect, select the newly created certificate that should be present and then enter the DN that maps to proper IP address of the firewall.  Commit and you should be good.

Now when the user tries to access a URL that falls within an override set category, their browser should be redirected via HTTPS to the DN, which should be mapped to the firewall.  If the cert is trusted, you should be set - no certificate warnings (assuming your cert was signed by a trusted authority).

Tariq

View solution in original post

11 REPLIES 11

L5 Sessionator

This is expected behavior and there is no way around it.  You can't load a wild card cert that would be accepted by other all other sites.

Thanks for the reply, are there any plans to change the behaviour?

I ask as we educate our users not to click on things if they're not 100% sure what they are etc. and I can imagine this causing a fair bit of confusion.

Could it be put in as a feature request please?

It seems like you are trying to put Fort Knox around a nickel. The only part worth protecting on that page is potentially the override password. A better solution would be to make SSL optional on the override page, or make it a 2 step process for a user to override.

1. Present an unencrypted block page with a button to override.

2. Present an encrypted password request page if the user wishes to override.

This would prevent the annoyance and confusion caused by a casual block and then you would only have to deal with the certificate mismatch when you truly wish to override the block.

As far as I'm concerned the override page doesn't have to be SSL at all, that was the default and I didn't spot an option for it to not be SSL - if that's possible I'm interested to know how?

L4 Transporter

So, can I use the override page without it using SSL?  I don't see anything obvious in the GUI or the manual on how to do so.

There is not currently a way to use the URL Filtering override feature without using SSL.

Like others said, there is not way to override the SSL used for the override page. I was making a suggestion that Palo Alto Networks make that SSL on the override page optional in a future revision of the PAN OS.

@nftech:

yes. you are correct. Since this feature does not exist it would require a feature request which you can request via your Sales Engineer.

Doesn't the URL Override redirect feature resolve this issue?  If you redirect to an interface IP or a DN that maps to an interface IP on the firewall and ensure that you're presenting an internally valid certificate, then the users shouldn't get any certificate errors.

Just got this working in my test environment a couple of days ago mysefl (running 3.1.4).  If I remember correctly, generate the cert 1st in the SSL VPN area of the certificates left hand link on the Device tab.  Once a cert has been applied, then go to the Setup left hand link of the Device tab and there should be a URL Override area on that page.  If you edit that area, you should be able to configure the specifics of the Override feature, including the Override type (redirect/transparent).  Set it to redirect, select the newly created certificate that should be present and then enter the DN that maps to proper IP address of the firewall.  Commit and you should be good.

Now when the user tries to access a URL that falls within an override set category, their browser should be redirected via HTTPS to the DN, which should be mapped to the firewall.  If the cert is trusted, you should be set - no certificate warnings (assuming your cert was signed by a trusted authority).

Tariq

Thank you so much!  Our reseller didn't mention this option.

It doesn't work on the management IP only on the LAN NIC, but it does work and suggests all I need to do is go buy a rapidssl or other cheap cert whose root CA is trusted on all our PC's (I know I could push one out but for $10 it's not worth the hassle).

Perfect!

(the only slight negative is that it seems I can't use the same cert for both URL admin override and for the management interface cert as I obviously can't have forward DNS internally mapping the FQDN to both the management and internal LAN NIC).

You're welcome Smiley Happy

Tariq

  • 1 accepted solution
  • 7239 Views
  • 11 replies
  • 1 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!