Dns filter and redirect portal IP

[nicolasross]

In our DNS filter profile, we have checked the redirect checkbox and selected to fortiguard default for the ip.

So when a client asks for a blocked website, it'll get the IP of the fortiguard portal, like 208.91.112.55.

When the site is in SSL, then the browser will generate a warning that the name on the certificate don't match the one on the site and that's true.

For SSL inspection we already have a private root installed on all devices on our network. Would it be possible for the fortigate to generate a certificate on the fly for this site so the user facing the issue will know that it's blocked instead of calling support to know what to do with the warning ?

[Markus]

Yes, you have to generate (with your CA) and import a cert to your forti and create an ssl inspection profile with this cert.

[nicolasross]

Not quite. Yes, we already have our own authority installed on the FG. But, as I have said, when it's the DNS filter that catches something, ti redirects to 208.91.112.55. It's the certificate from this IP (*.fortinet.com) that is prsented, and not one for the site the client was visisiting.

[Markus]

Sorry, I've misunderstood. That's another thing in this case, I apologize. I'm new with DNS Filter and don't know how to solve that. I made a policy for our AD Servers -> wan -> DNS and applied a DNS Filter. In the meaning that would deny any DNS request to the blocked categorys, but the user wouldn't see a block page. Maybe I'm completely wrong or misunderstood the DNS Filter thing. What if you setup (if you can) a small webserver with a response page and present a "real" cert? Then point to this URL instead of Fortiguard. Best

[nicolasross]

You're exactly right. If I refuse the query, users will get a "domain not found" on their browsers, which will make users asks sysadmins why this is site isn't working here, as it was at home. So redirecting the users to the fortiguard IP, they get a certificate warning, which isn't better.

That's why I wanted to show them a proper page with a valid certificate.

I could use one of our internal ip, but I'll have to manage to mint a certificate on the fly myself on that server.

[Markus]

ok, I see the problem. Maybe it could work with a policy from client -> your webserver and use ssl inspection, the presentet certificate should then be ok as its coming from your Forti. This is an interesting case, I have to re-think this for us too.

[nicolasross]

Even with ssl inspection, the certificate that is presented is the one sent by the remote server, hence *.fortinet.com, not for the hostname that the client asked.

I think the solution would be to have an internal server with some nginx, apache or whatever that could mint a certificat for whatever the client asks.

[smassey]

I'm running into this same issue with cert warning when redirected. Did you ever come up with a solution?

[nicolasross]

smassey wrote:

I'm running into this same issue with cert warning when redirected. Did you ever come up with a solution?

No I haven't The only solution would be to redirect the users to an internal IP where we could have a server generate a certificate on the fly. It's too bad the gate can't do it, as it can generate certificate easily for certificate inspection...

[Bonus45]

I wish there was a better way to handle the whole redirect portal.  The Fortiguard Portal page is unprofessional looking and not helpful to users or admins.  The fact that it presents a user with a non-https page is just a bonus hassle as we tell users to not click through those warnings.