4 ms·

If you're in a corporate intranet environment, you ought to have an intranet CA, as well as the means to distribute the CA's certificates securely to all deploy

If you're in a corporate intranet environment, you ought to have an intranet CA, as well as the means to distribute the CA's certificates securely to all deployed machines within the intranet.

tempay 9y ago
That's okay unless you allow users to bring there own devices, then you have users which are taught to bypass certificate errors on a daily basis.
- bjpbakker 9y ago
  Sorry but I have to call BS on that. I always bring my own device and never have bypassed certificate errors. A company will either have certificates for their own apps (commonly running on specific subdomains of their own domain) or have their own internal CA that you can trust on your own device. Certificate errors on "internal" web apps are just as bad as on the rest of the internet.
  - wfunction 9y ago
    If you trust a company's internal CA then aren't you trusting them to issue certificates for every website and not just their own? Isn't that dangerous?
    - bjpbakker 9y ago
      Yes absolutely. If I have to I trust the company's CA in a special browser profile that I only use for working with their internal tools. For just a few tools it's often simpler to just trust those specific certificates, though
    - ewanm89 9y ago
      All browsers can tell you what certificate signed the one in use. Unfortunately a recent chrome UI change made this a pain to get to.in chrome, into the other browsers just clicking on the lock in the address bar, it soon becomes obvious if the company is mitm all SSL connections.
      - wfunction 9y ago
        Because a normal person will "just click the lock in the address bar" on every single HTTPS website he visits to make sure his company isn't MITMing him, right?
tajen 9y ago
I dislike intranet CAs because they allow your company to intercept and play MITM with every other website you visit (except for certificate-pinned websites)... I'd prefer that Chrome write "insecure" if there's a non-public CA in your chain.
- bjpbakker 9y ago
  It depends on what they're used for but I agree that many companies seem to spy on their employees this way. Commonly I only allow internal CAs for specific internal websites and not allow them to MITM just any website. On occasion this meant not being able to use the company's wifi and deal with 4g instead.
- RJIb8RBYxzAMX9u 9y ago
  If it's a company issued device, then play by their rules. If it's BYOD, then create a new user account / profile for work. We're not running DOS anymore.
- phlo 9y ago
  Minor nitpick regarding the "except for certificate-pinned websites" part: HPKP does not validate pins if they resolve to a user-installed trust anchor like an intranet CA. The RFC [1] leaves behavior undefined (see Section 2.4), and I'm not aware of any popular implementation that would honor the pin in case of a user-installed certificate. This can be incredibly frustrating if you're trying to protect against MITM attacks; but at the same time, I can follow the browser developers' line of thought that goes "if we were to enforce it, users would just jump ship to the next available browser". [1] https://tools.ietf.org/html/rfc7469 https://tools.ietf.org/html/rfc7469
  - cesarb 9y ago
    At least on firefox, this can be changed through the preference security.cert_pinning.enforcement_level (see https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...).
- solatic 9y ago

If you're in a corporate intranet environment, you ought to have an intranet CA, as well as the means to distribute the CA's certificates securely to all deployed machines within the intranet.

tempay 9y ago

That's okay unless you allow users to bring there own devices, then you have users which are taught to bypass certificate errors on a daily basis.

bjpbakker 9y ago
Sorry but I have to call BS on that. I always bring my own device and never have bypassed certificate errors. A company will either have certificates for their own apps (commonly running on specific subdomains of their own domain) or have their own internal CA that you can trust on your own device. Certificate errors on "internal" web apps are just as bad as on the rest of the internet.
- wfunction 9y ago
  If you trust a company's internal CA then aren't you trusting them to issue certificates for every website and not just their own? Isn't that dangerous?
  - bjpbakker 9y ago
    Yes absolutely. If I have to I trust the company's CA in a special browser profile that I only use for working with their internal tools. For just a few tools it's often simpler to just trust those specific certificates, though
  - ewanm89 9y ago
    All browsers can tell you what certificate signed the one in use. Unfortunately a recent chrome UI change made this a pain to get to.in chrome, into the other browsers just clicking on the lock in the address bar, it soon becomes obvious if the company is mitm all SSL connections.
    - wfunction 9y ago
      Because a normal person will "just click the lock in the address bar" on every single HTTPS website he visits to make sure his company isn't MITMing him, right?

tajen 9y ago

I dislike intranet CAs because they allow your company to intercept and play MITM with every other website you visit (except for certificate-pinned websites)... I'd prefer that Chrome write "insecure" if there's a non-public CA in your chain.

bjpbakker 9y ago
It depends on what they're used for but I agree that many companies seem to spy on their employees this way. Commonly I only allow internal CAs for specific internal websites and not allow them to MITM just any website. On occasion this meant not being able to use the company's wifi and deal with 4g instead.
RJIb8RBYxzAMX9u 9y ago
If it's a company issued device, then play by their rules. If it's BYOD, then create a new user account / profile for work. We're not running DOS anymore.
phlo 9y ago
Minor nitpick regarding the "except for certificate-pinned websites" part: HPKP does not validate pins if they resolve to a user-installed trust anchor like an intranet CA. The RFC [1] leaves behavior undefined (see Section 2.4), and I'm not aware of any popular implementation that would honor the pin in case of a user-installed certificate. This can be incredibly frustrating if you're trying to protect against MITM attacks; but at the same time, I can follow the browser developers' line of thought that goes "if we were to enforce it, users would just jump ship to the next available browser". [1] https://tools.ietf.org/html/rfc7469 https://tools.ietf.org/html/rfc7469
- cesarb 9y ago
  At least on firefox, this can be changed through the preference security.cert_pinning.enforcement_level (see https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...).
solatic 9y ago