That is the way SSL proxies work.
You tell the browser to go to https://www.example.com/ and it expects
the received certificate to be either www.example.com or *.example.com
and signed by a CA that it has in its trusted CA repository.
So, there are only two possibilities...
1) allow the encrypted stream untouched
2) the proxy needs to intercept the connection, establish its own
connection to the server, then act as the server to the client.
To act as the server, it has to have the server certificate and the
private key. The server certificate that it presents to the client must
be signed by a CA trusted by the client and the public key in the
certificate must be the counterpart of the private key that the proxy
has access to.
Server (public CA) <--> proxy
proxy (private CA) <--> client
Because you are presenting certificates to the client for servers that
you don't know before hand, the proxy must have the CA private key to
sign the certificates on the fly. The private CA certificate must be
installed in all clients to be trusted. And it must have the CA:true
constraint.
In the windows world, you can push out a private CA certificate with a
GPO in Active Directory. Most others, you would have an internal
website that allowed the download and install of the CA certificate.
The certificate download should be in DER format. Most browsers will
auto install with these headers:
Content-Type: application/x-x509-ca-cert; name=private-ca.crt;
Content-Disposition: attachment; filename=private-ca.crt;
Windows:
Download and run. Windows will identify it as a root CA certificate and
open the certificate dialog. Click on the "Install Cert" button.
Firefox:
Firefox will automatically recognize it as a certificate and start the
import.
Chrome:
On Linux you must download and follow these instructions:
http://code.google.com/p/chromium/wiki/LinuxCertManagement
Safari:
Download and run. MacOS will identify it as a root CA certificate and
ask if you want to install it.
I had a lab at Symantec that my team and I created to dynamically bring
up a development environments with dynamic URLs to access. I had scripts
that would auto generate a CSR and POST it to a web service that blindly
signed any CSR given to it. It was a quick and dirty solution and tiny
CGI script. :)
You can't use a wildcard certificate because the "*" only accounts for
one level.
*.example.com matches www.example.com and blah.example.com, but not
www.blah.example.com.
Of course that restriction is up to the client implementation. But,
that is one issue I had run into in the past.
On 10/09/14 16:46, Ski Kacoroski wrote:
Hi,
I need someone with more certiticate-fu than I have. I have an iBoss
web filtering device that sits in between our internal users and the
internet. We are trying to set it up to also filter https web pages
which means it has to decrypt the connection to see what is going on.
They are claiming that we have to use a self-signed cert on their device
instead of our wildcard *.nsd.org cert and then install the public key
on all the browsers of our internal machines which, as you can imagine,
is not something we want to do or maintain. I have 6500+ macs, 3000
chromebooks, 2000 ipads, 1000 windows, and several hundred other things
such as kindles, etc. In addition, several of these have multiple
browsers.
I appreciate any comments or ideas why we cannot get our wildcard cert
to work (it works with erverything else except for an old Oracle
application server where I had to get a machine specific cert).
Their description is:
--------------------------------
* The certificate needed to do the decryption must be trusted by the
browser to sign ALL domains.
* GoDaddy and other Certificate Authorities (CA) will not sign a
certificate for use with domains other than your own. So… The
certificate must be self-signed with no verification path back to a
trusted CA.
* The *.nsd.org certificate you have will work to access the iboss UI,
block or login pages.
Follow up email states:
The first 2 bullet points from yesterday are important to understand.
There is no possibility of getting a CA certificate from anyone that is
trusted by the browsers. As far as we have seen it takes a CA cert to be
fully functional for intercepting HTTPS traffic and re-sign so that the
browser will accept it. This means using a self-signed cert. To stress
the point, imagine what damage you could do with a certificate that
allowed you to pose as Google without the browser alerting the user.
I can’t answer why we have had the limited success with decrypting using
the *.nsd.org or how far we can push it. In a couple cases we were able
to get everything working unless Chrome was used. In another case IE
seemed to be the biggest problem. They each perform validity checks of
their own design. Technically, the cert you have should not be accepted
to sign anything. That is not a feature of the cert (CA:FALSE).
--------------------------------
cheers,
ski
--
Mr. Flibble
King of the Potato People
http://www.linkedin.com/in/RobertLanning
_______________________________________________
Discuss mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss
This list provided by the League of Professional System Administrators
http://lopsa.org/
