I noticed within a corporate network the issuer for for sites with LE certificates is different than when loaded up outside the network. It shows the certificate is issued by a corporate firewall.
I mainly bring this up as I have a site with an expired certificate from LE... Within this network it says valid and I can access the site without any warnings and outside of the network it obviously shows expired. Please help me understand what this means and if I should be concerned.
See the attached screenshot of within the network and outside of the network showing the certification path for letsencrypt.org and how they are different.
I suspect that if you go to any Internet HTTPS site from within your corporate network you will see the same certificate chain.
If so, that means that your "MWG FIREWALL" is doing SSL inspection and must "break" your connection and insert itself in the secure path ("MITM") to see, and stop anything malicious, when corporate systems connect to Internet systems.
If your cert is seen as expired from the Internet, then it needs to be renewed; as that is what the world is now seeing.
First off, this isn't the "issuer" - that is specified in the Certificate Details.
Blurring the following, because I was wrong and @rg305 is right. See my next post.
I don't think the firewall inspecting SSL is possible, because the HTTPS exchange is between the browser and server. It's possible there is some extension to the OS/Browser that allows this, but I doubt it.
What I think is happening, is that your corporate IT department has removed the trusted roots from the OS or prioritized their own. Then they signed the LetsEncrypt public key with the firewall private key to make it trusted within the environment.
Browsers build Certificate Paths in weird and unpredictable ways, and will often use a cached key. The path shown in this dialogs is rarely the actual path specified by the server, it's just noting the first valid path the chain building logic determined. The Server's specified fullchain is really a "hint" for the clients, and not a prescribed/required/determined chain. There are many posts about this in the forum, usually where browsers would show a direct chain to a LetsEncrypt root when the site specified a cross-sign and vice-versa.
A quick way to test this would be to use FireFox - which ships with it's own root store (Chrome will be doing this shortly too). If you still see a weird Certification Path, I would have some concern over what corporate IT is doing - but you're likely to see the expected normal chain.
Edit: I'm not sure exactly how the IT department would do that, and it's too late for me to think about this in-depth. The corporate IT department is doing something weird here, but I'm not convinced it's necessarily troubling.
Actually, I am revoking what I said before. @rg305 is right and i was wrong. I looked up MWG Firewall and their docs -- they offer a complex MITM SSL Inspection tool.
Your computer is not connecting directly to LetsEncrypt. Basically, the gateway is pretending to be LetsEncrypt and proxying your requests so the raw data can be inspected. To make this seem legit to your browser, they rebuild a certificate chain that chains up to their trusted root.
That is very interesting... Where is this in the docs? So traffic to the inspection tool appears plain text? Or is it more just scanning for malware and other bad things?
It is intended for automatically scanning traffic for malware/bad-stuff, but doing so requires terminating SSL so they can inspect all the traffic as plain-text.
The firewall can see all traffic going through it by doing this, yes. These kinds of systems automatically "issue" certificates for every site one visits on their network to itself, so to your browser it can pretend to be the website. Then it does its own connection to the real website, gets the page, does whatever inspection it wants to, and then (if it passes its checks) sends the content to your web browser.
Because these issue their own certificates for everything, obviously they aren't trusted by default by web browsers. But computers on the corporate network (being owned by the company) have been configured by the system administrators to explicitly install and trust the firewall's root certificate.
These kinds of things are more common than you might expect. It also might only do the man-in-the-middle for DV certificates and not for like, EV certificates or other "trusted" sites. It like, sniffs the certificate being used (which is generally sent unencrypted by the server) and uses that to determine whether or not to intercept the connection. So that might explain why you are only seeing it for Let's Encrypt sites and not, like, your bank or the like.
This is one of those many systems doing MITM-like TLS inspection... In my university we call it Split TLS, as you're effectively splitting your TLS connection into two, with the firewall = middlebox in between.
This gives up all end to end encryption on the connection*, instead fully relying on the middlebox to do things like authentication. Is this concerning? Depends on if you trust the middlebox.
What worries me most here is that you're saying that the certificate is expired, yet your local (spoofed) certificate is valid. This means that the firewall software (middlebox) doesn't validate expiry dates on remote certificates - maybe it doesn't validate server certificates at all, circumventing all authentication normally provided by the TLS system. We see this type of behaviour often in so-called security software, sometimes doing more harm than helping. Breaking TLS is never a good solution, though often the only option thanks to policy.
(Sorry for the partly unrelated rant, hopefully this was at least remotely useful)
*In fact, you're loosing everything TLS gives you: With a middlebox, you have neither authentication, nor confidentiality nor integrity
I remember a great presentation about this exact issue from Jeff Jarmoc at Black Hat Europe
The overall point is that the intercepting proxy isn't necessary as strict or as skeptical as your browser would be in deciding what to trust, in various ways.
