We have SSL proxy service running on our SRX1500 and everything is working. The minor issue I have is that the certificate presented to users (generated by the SRX1500) is signed using a SHA1 hash algorithm . This causes Google Chrome to mark the website with a "caution" on the URL bar instead of a "green padlock". We have a local CA and all domain computers are loaded with the correct root cert so there's no problem there as far as trusting the "website".
My question is, is there a way to change how the SRX1500 signs the certificate before they are sent to the users? I can't seem to find any setting at all that relates to this. I want to make the SSL inspection service as transparent as possible...
If you have your own CA internally, like a MS server environment, your best bet is to issue a certificate request from the SRX to your internal CA and then load and use that certificate. These will be fully trusted then by your domain computers.
The certificate loaded on the SRX1500 is issued by our CA using the steps described on the link you provided.
From a client PC, the SRX1500 certificate is already trusted since it inherits the trust from the CA which is already loaded on all domain computers. It's just that the SRX1500 signs each web certificate it proxies using SHA1 which makes Google Chrome complain. Using the "custom-ciphers" configuration stanza doesn't seem to matter
Have you found any resolution to this? From my understanding the SRX should be inheriting the hash algorithm from its own certificate but this does not seem to be happening as im having the same problem - for some reason it is presenting sha1 certificates on the client side while maintaining sha256 throughout the rest of the certificate chain....
Ive gotten one open and have run through a couple kbs so far to no avail - ill post back soon as we figure it out. - hopefully between the two of us they can get this sorted...kinda makes the sky atp useless if it downgrades all ssl sessions
So you were wise to not waste your time - took a few days and escalation to find out sha256 wont be supported till mid17 - so at this point if its a non ie only environment your stuck with not transparent proxy or else only scanning http traffic....
The only thing that is preventing SSL forward proxy from working seemlessly with the major browsers is as you report the SRX when doing SSL-T-SSL (generating the certificate between the firewall and the client), the SRX generates the certificate with SHA1, even though your root certificate may be signed in SHA-256
IE & Firefox are OK with SHA1 signed certs as of April 2017, however google Chrome puts up the errors
## from config menu: set services ssl traceoptions file ssl-proxy set services ssl traceoptions flag all set services ssl proxy profile test-sslp trusted-ca cag2017 set services ssl proxy profile test-sslp root-ca self-cert2017 set services ssl proxy profile test-sslp actions ignore-server-auth-failure set services ssl proxy profile test-sslp actions log all set services ssl proxy profile test-sslp actions log errors
set security policies from-zone trust to-zone untrust policy outbound-ssl match source-address any set security policies from-zone trust to-zone untrust policy outbound-ssl match destination-address any set security policies from-zone trust to-zone untrust policy outbound-ssl match application junos-https set security policies from-zone trust to-zone untrust policy outbound-ssl then permit application-services ssl-proxy profile-name test-sslp
## Now export the certificate from the firewall for import into Windows (for ie and chrome) and Firefox request security pki local-certificate export certificate-id self-cert2017 type pem filename /cf/var/db/certs/common/local/srx-root-ca2017.pem <--- physical request security pki local-certificate export certificate-id self-cert2017 type pem filename /cf/var/db/certs/srx-root-ca2017.pem <--- vSRX
## SCP into the firewall and grab the .pem file and rename it to .crt ## import the .crt file into machine TRUSTED ROOT CERTIFICATE AUTHORITIES