Smoothwall root cert not fully OpenSSL compliant?

[Bruce123]

We have been testing a new product called eSafe (from http://www.esafeglobal.com).

 

It logs what students are typing and performs SSL interception on the computer to decrypt traffic between the the browser and the proxy.

 

The problem is it doesn't work properly and when esafeglobal have investigated they said the issue is because the "Smoothwall Root Certificate is not fully SSL compliant". We use Smoothwall operating in transparent mode (bridging).

 

Their advice is to upgrade Smoothwall to (at least) Kenilworth, re-create the root cert and re-deploy it to the clients. That's a non-trivial task, as we have had to manually install the cert to non-domain joined wireless devices. Domain-joined Windows have the cert pushed out via Group Policy, so this shouldn't be too bad.

 

We are currently on Leeds-4 (>Kenilworth), but I don't know what version Smoothwall was when the root cert was generated (or even that it was created by Smoothwall but it probably was).

 

Anyway, the implication seems to be that an there was bug in an older version of Smoothwall that led it to create a certificate that wasn't 100% compliant with the standards. Has anyone heard of this, or have any experience of using eSafe with Smoothwall?

 

Many Thanks,

 

Bruce.

[CCCSecMan]

Yes known bug (now fixed), the other thing you could do is put pressure on esafe to change their code such that it can cope with the certificate error.

 

If you're a small single site just regenerate a new HTTPS interception certificate and roll out, that is probably the easiest bet.

 

Was fixed in Kenilworth-4 iirc - think something alludes to it in the release notes actually if you have a gander.

[Bruce123]

Yes known bug (now fixed), the other thing you could do is put pressure on esafe to change their code such that it can cope with the certificate error.

 

If you're a small single site just regenerate a new HTTPS interception certificate and roll out, that is probably the easiest bet.

 

Was fixed in Kenilworth-4 iirc - think something alludes to it in the release notes actually if you have a gander.

 

Thanks for the info.

 

eSafe confirmed that there wasn't a problem with the interception cert (only the root), so as a test we tried adding the interception cert to the list of trusted root CAs on the test PC and it resolved the issue (no errors). I guess the eSafe software doesn't check all the way up to the root of the certificate chain if one of them in the chain is explicitly trusted by Windows.

 

Thanks,

 

Bruce.

[Bruce123]

Just to update everyone on this issue.

 

Adding the interception cert to the list of trusted root CAs on the client PCs didn't resolve the issue as we originally thought (the validation tool used by eSafe verifies certs right the way up the chain).

 

Looking into the issue of the validity of the original Smoothwall root CA cert, eSafe used the Libre opensll.exe tool to demonstrate an that the format of the start/expiry date fields don't conform to the relevant RFC for x509 certs. And Smoothwall's suggestion of disabling the SSL interception feature of eSafe to resolve this issue would seem to negate one of the main features of the product.

 

In the end we generated a new root CA cert in Smoothwall and used the same opensll.exe tool to verify compliance (no issues were found with date formats with the new cert).

 

And, as of today we are using it (or more precisely, the new interception cert) for SSL interception in Smoothwall and is working fine.

 

We have't yet tested compatibility with eSafe...

 

Thanks,

 

Bruce.

[gshaw]

Have had constant issues with Smoothwall and eSafe not playing together nicely, getting bored of it now and seems more Smoothwall's end. We had the Kenilworth fix, which helped initially then we found another bunch of errors with Google not so long ago as well.

[Bruce123]

Have had constant issues with Smoothwall and eSafe not playing together nicely, getting bored of it now and seems more Smoothwall's end. We had the Kenilworth fix, which helped initially then we found another bunch of errors with Google not so long ago as well.

 

That's interesting to hear... Did either party give any indication as to the cause of the issues?

 

Thanks,

 

Bruce.

[gshaw]

That's interesting to hear... Did either party give any indication as to the cause of the issues?

 

Thanks,

 

Bruce.

 

eSafe say the libressl library is very particular about SSL compliance and therefore it's down to something Smoothwall is doing