Download Zscaler Certificate WORK
Karlyn Melich
I must confess to not getting a chance to properly investigate the approach described above. The change to the new file handling framework does, however, allow trusting all certificates for the nodes that allow file connection ports so the workflows can access the sites (properly vetted of course) without needing to add in the certificate.
I just realized I forgot to respond to your previous post. I am surprised the curl tries to take the information from the issuer certificate itself instead of using the information embedded into the x509 certificate.
Those are two different layers: of course it is possible to add the ca certificate used by TLS inspection to the docker demon. As TLs inspection breaks the security context to the registry, you will need to treat it like a secure private registry:
A secure registry uses TLS and a copy of its CA certificate is placed on the Docker host at /etc/docker/certs.d/myregistry:5000/ca.crt. An insecure registry is either not using TLS (i.e., listening on plain text HTTP), or is using TLS with a CA certificate not known by the Docker daemon. The latter can happen when the certificate was not found under /etc/docker/certs.d/myregistry:5000/, or if the certificate verification failed (i.e., wrong CA).
Well there is a need, because currently I get certificate validation errors when building containers, and those are caused by Zscaler and its TLS certificate. We need to test the images on our development machines in some cases, so we need to be able to configure Docker Desktop to trust the enterprise certificate authority.
You can still have development images with the only difference that you add certificates. Depending on who and how will deploy the containers you can also bind mount the certificate bundle file (the one that contains all the certificates) into the containers, but you need to know which distribution or applications expects it where. In case of Ubuntu, the current documentation says
This has been a problem for a long time. I found a solution a year or so ago, but had to stop using Firefox until recently. I simply can't remember or find that solution now. There were lots of certificate workarounds, but then I came across a solution that was a beta setting in Firefox that solved it. That's what I can't find now.
Basically a lot of websites give me the "Your connection is not secure" message, due to the fact that my computer is using the corporate certificates, so Firefox assumes it's a bad cert. I love and want to use FF, but it's the only browser that can't figure this out. Anyway, like I said above, there was a beta setting a long time ago, and I can't remember or find it now. It fixed this "problem" and allowed me to use FF at work.
In the search box at the top of the page, type cert and Firefox should filter the list. Click "View Certificates" to open the Certificate Manager and click the "Authorities" tab. Then you can use the "Import" button to import the proxy server's certificate. (Fourth and fifth screenshots.)
(2) If the signing certificate is in the Windows certificate store (for example, IE and Chrome trust it), you could set Firefox to trust everything that Internet Explorer trusts by having it check for authority certificates in the Windows certificate store.
In order to fix this, you need to get a copy of the root certificate file that your company is using, and import it into Firefox. This post describes how to do that: -US/questions/1194482#answer-1049259 . Can you try out the instructions there, and see if that works?
Unzip the file and create a new configuration profile in Intune. Click Devices > iOS/iPadOS > Configuration Profiles > Create Profile > Select Profile Type Template > Trusted Certificate. Upload the previously downloaded certificate. Assign the certificate to the user group!
You can verify if that ZScaler's bug is the root cause by closing all Edge instances and hitting Win+R, then running
msedge.exe --disable-features=PostQuantumCECPQ2
If that works, then something on your network path is not compatible with large ClientHello messages in the HTTPS handshake. For instance, older versions of ZScaler are known to have a bug whereby they fail to see the ServerNameIndicator TLS extension if the ClientHello spans multiple packets, and when that happens, the server typically will return the wrong certificate, resulting in a NET::ERR_CERT_COMMON_NAME_INVALID error message. ZScaler has released a fix for this that you'll need to apply.
In other cases, the network device is completely incompatible with handshakes that span multiple packets and an ERR_CONNECTION_RESET will be seen instead. You'll need to talk to your network administrators about contacting the vendor of your networking equipment about getting a fix.
The reason this issue appeared and disappeared only to reappear again is because the PostQuantumCECPQ2 feature was changed to "off-by-default" for version 80/81 but it is now enabled again for version 82.
The upstream issue can be found here:
If you are using a non-standard set of certificates, then therequests package requires the setting of REQUESTS_CA_BUNDLE.If you receive an error with self-signed certifications, you mayconsider unsetting REQUESTS_CA_BUNDLE as well as CURL_CA_BUNDLE and disabling SSL verificationto create a conda environment over HTTP.
Open Chrome, got to any website, click on the lock icon on the leftof the URL. Click on Certificate on the dropdown. In the next windowyou see a stack of certificates. The uppermost (aka top line in window)is the root certificate (e.g. Zscaler Root CA).
To set this permanently, open your shell profile (e.g. .bashrc or .zshrc) and add this line: export REQUESTS_CA_BUNDLE=/path/to/converted/certificate.pem.Now exit your terminal/shell and reopen. Check again.
Click Upload metadata file at the top, and select the zscaler-metadata.xml file you downloaded from the ZIA admin portal earlier. This will open a panel and pre-populate some of the required info.
IMPORTANT: The certificate will download as a .cer file. You must change the file extension to .pem or it will not be able to be used later on. DO NOT just download the certificate in .pem format as this will cause user authentication to fail. The certificate downloaded must be the Base64 certificate in .cer format, renamed to .pem.
If sign in passes Microsoft SSO, but you get a Zscaler error (as per the image below), check the error code in the bottom right corner against the list of error codes here. This indicates an issue with the config on the Zscaler side (typically something to do with the certificate you imported from Azure AD).
Is it possible to import the web proxy CA certificate and private key (the CA on the web proxy that signs certificates for HTTPS websites on the fly) onto the Palo Alto and if so, would the Palo Alto firewall be able to use the CA certificate and private key to see inside the certificates the web proxy creates on the fly?
I'm thinking this is not possible, as the web proxy creates a new certifcate public/private key for each HTTPS website the user visits, and I don't believe the Palo Alto can use the CA certificate and private key to decrypt certificates that it has signed. Would love to hear comments?
The answer to your question would be "it depends" because you don't make mention of what's actually acting as a proxy. Some proxies will allow you to issue a subordidant CA Cert to the firewall and allow the firewall to issue the cert on their behalf and then simply accept that certificate and perform other functions, others won't. If your proxy can't do that, or something similar, then it would need to be able to pass the unencrypted traffic through to the firewall for inspection before returning the traffic and encrypting it again; this however is an extremely uncommon feature and something you probably wouldn't want to enable unless you have some sort of encrypted tunnel to the proxy service.
The proxy is a Zscaler. My fundamental question that I'm trying to get my head around, is this; if I download the subordinate CA certificate + private key running on my Zscaler onto my Palo Alto, would this be suffice for my Palo Alto firewall to decrypt the HTTPS traffic (SSL Inbound Decryption)?
I think the answer is no - the Palo Alto needs the certificate + private key of the websites I am visting (so if I browse to my Palo Alto needs the certificate + private key that was created by the subordinate CA running on my Zscaler). Does that make sense?
Not yet, we have opened up a ticket with Cisco support for help. Their first recommendation was manually adding a few certificates to the users computer, but that did not fix it. It is something to do with our VPN client called zScaler. If I turn off the VPN client the Webex app works.
df19127ead