SSL Inspection policy failing to use new certificate

[x_member]

Fortigate 60D v5.2.11

We've had cause to re-issue the certificate that we use for deep inspection on outbound traffic (moving from SHA-1 to SHA-256). This certificate has been installed as trusted on all affected internal clients.

To try and ensure a smooth transition, I've installed the new certificate and set it for use in a cloned copy of the outbound deep inspection SSL inspection policy, leaving the original SHA-1 certificate used by the original outbound inspection policy.

I've switched one of the firewall rules for traffic to use the new SSL inspection policy with the SHA-256 certificate. 

That was 50 minutes ago, however the fortigate is still utilising the original SHA-15 certificate for inspection (as checking any inspected HTTPS website certificate chain confirms). This behaviour is replicated across multiple clients and browsers (IE11, Chrome, Firefox).

I'm assuming that the Fortigate has cached the old certificate. 

Rebooting the firewall is not an option.

How do I 'encourage' the firewall to respect this configuration change and begin using the new SHA-256 certificate to inspect outbound traffic? Is there a process I can restart without interfering with other functionality / traffic?

[tanr]

I think clearing the ssl certificate cache is done with

diag test app ssl 12

Details at http://kb.fortinet.com/kb/viewContent.do?externalId=FD32679

[x_member]

Unfortunately 

diagnose test application ssl 0

is rejected as a command parse error.

Substituting 'debug' for 'test' and trying 0, 12, and 99 options returns no error in the CLI and no output.

Symptoms remain unchanged with the certificate chain showing the 'old' SHA1 certificate.

I'm not sure the ssl application is present anymore (per https://forum.fortinet.com/tm.aspx?m=135228)

I've also tried restarting proxyworker, with no change to the symptoms. Very frustrating.

[emnoc]

Can you  do any of the following

1: disable the ssl-inspection , wait and then re-enable

or

2: disable and  then re-enable the  fwpolicy-id <xxx>

Does that fix the issue?

[x_member]

emnoc wrote:

Can you  do any of the following

1: disable the ssl-inspection , wait and then re-enable

or

2: disable and  then re-enable the  fwpolicy-id <xxx>

Does that fix the issue?

Tried 1 yesterday (which I should have mentioned - apologies) - removing the ssl-inspection for about 1/2 hour made no difference, with HTTPS browsing still intercepted and re-encrypted using our certificate.

I've tried 2 this morning after coming in early - no dice.

I've now also tried removing SSL inspection from the policy, deleting the new (cloned) inspection object and recreating it from scratch in case there was an issue with cloning.

After applying the fresh SSL inspection object to the policy the chain still shows the old certificate in use.

[tanr]

Ah, sorry - didn't realize that was out of date.

Don't suppose it's in the wanopt webcache?

[x_member]

tanr wrote:

Ah, sorry - didn't realize that was out of date.

Don't suppose it's in the wanopt webcache?

No worries.

I don't know anything about wanopt webcache I'm afraid - the 60D doesn't support SSL Offloading AFAIK (which I believe is related based on a very quick search?).

I find no reference to it in a config backup.

[x_member]

At this point I've:

- updated the original ssl inspection policy to point to the new (sha256) certificate

- deleted the old (sha1) certificate from the FGT appliance.

- removed the new inspection policy.

Yet all indications show that the FGT appliance continues to use the original cert.

*Update*

It seems that I need to locate the 5.2.x branch equivalent of clearing the ssl certificate cache

diagnose test application ssl 12

We are seeing the new certificate on sites not (recently) visited, however the majority of sites still show the old certificate in the chain.

Obviously I've ensure that browser caches are cleared etc. - this behaviour can be seen on multiple clients, in multiple browsers and persists through reboots etc. hence my seeking a FGT cache clearing mechanism.

[packetpusher]

Did you solve the issue?

[x_member]

mstoyanoff wrote:
Did you solve the issue?

Nope. Still needing to find out how to clear the cache - symptoms still as last described. I'm UK based and have left it over the weekend in case it's time based. All suggestions still welcome.