Help understanding Certificate usage on the WSA

[DamianRC]

I'm troubleshooting a  WSA certificate issue.

Local users access web provided resources located at HQ.

This traffic traverses a WSA.

The local user browser sessions report an insecure connection when accessing the HQ site.

This connection should be secure. How can this be done?

I understand that HQ's Root Cert should be installed on the WSA, but is it installed under the HTTPS Proxy section(where a Key would also be needed), or Network/certificate management /manage trusted root certificates? What's the difference between the two?

I don't understand the certificate arrangement from the WSA's perspective well enough. Thanks for helping

[Ken Stieers]

It goes in the https proxy section.


You don't have to use the root, you could also generate a subordinate signing certificate (as if you were creating an issuing ca) and use that.


The cert in the https proxy section is used to generate the cert for the communication between the WSA and the workstation, on the fly, matching the name of the site that the user is surfing.

The certs in the trusted roots are the published roots of the various commercial CA's like the ones you see on a workstation that MS updates for you via patches. They are used to validate the certs/chain's that the WSA gets from websites when it does the browsing for you.

[DamianRC]

Thanks for replying, Ken.

This is interesting. If I do what you recommend, the HQ cert wouldn't be
required, then? And would sessions to the HQ web sites become secure?

Thanks again

[DamianRC]

Thanks for replying Ken.
Would the subordinate signing cert be generated on the WSA?

[Ken Stieers]

No, you generate that cert from the CA you have installed.

Lets take a couple of steps back to make sure I don't have you chasing stuff you already have working.

It sounds like you have HTTPS proxy on and configured... When your users go to an SSL site, google for example, do they get a cert error?  or is it just the HQ sites that you're having the bad cert issue with?

[DamianRC]

You are correct.

There is an HTTPS proxy configured.

Users do not get cert errors when browsing to SSL sites, only the HQ sites.

A security exception is required to access the HQ sites. The connection is also reported as not secure.

HQ has made available certs in files with .crt extensions. I've uploaded these to the certificate management section to no avail. HQ's intent for the files is for users to apply them to their browsers. It's more efficient for us to apply them to the WSA, through which all web-based HQ destined traffic must traverse.

Is the .crt the right file extension? Should it be .pem?

Thank you

[Ken Stieers · Accepted solution]

Do this instead... from your workstation, go to the WSA an put your machine's current IP in bypass, under WebSecurityManager/BypassSettings.  Submit/Commit.

Now go to the sites you're getting the error from using IE.  (if you're on Win10, you have to "Run as Administrator for the following to work)

You shouldn't get a cert error....

Click on the lock in the address bar, and select View Certificates.  Click on the "Certification Path" tab, select the top/root cert, click on View Certificate button.

Go to the Details tab, and click "Copy to file..."

Save it as a Base-64  .cer file and upload that to your WSA under Network/Certificate Management.

Submit/Commit

Test it on another machine...

You may want to get any intermediate certificates if they're using them (all from the Certification Path tab)

[DamianRC]

Excellent. Thank you Ken.

I will store this procedure for future reference.

It turns out I had the certificate on file already. After you helped me understand where it should be loaded, I did it and didn't see results.

I hoped on a call with Cisco support, and they advised I console into the filters and run the following hidden commands: diagnostic > PROXY > kick.

This worked. Connections to HQ are now secure.

Thank you!

[Ken Stieers]

Yep, sorry about forgetting about proxy kick...

Don't forget to pull your machine out of bypass. :)



Not sure what version you're on, but you may come across other sites on the internet where you get a similar error. You can use grep the access log via the command line, and see if its generating an untrusted root cert error... sometimes it's the root that the WSA needs, and sometimes it has the root but can't get the intermediate correctly, so you can load the intermediate, just like you loaded HQ's root.

I haven't had to do it much since 10.0.3... but if you're still on 9.x it may pop up.

[DamianRC]

Duly noted! Thank you very much!