6 ms·

Just commented over at Matthias' blog, I'll just copy-paste it here: First of all I think this is generally a good move. If people use random TLDs for testing

by hannob 9y ago

Just commented over at Matthias' blog, I'll just copy-paste it here: First of all I think this is generally a good move. If people use random TLDs for testing then that’s just bad practice and should be considered broken anyway. But second I think using local host names should be considered a bad practice anyway, whether it’s reserved names like .test or arbitrary ones like .dev. The reason is that you can’t get valid certificates for such domains. This has caused countless instances where people disable certificate validation for test code and then ship that code in production. Alternatively you can have a local CA and ship their root on your test systems, but that’s messy and complicated. Instead best practice IMHO is to have domains like bla.testing.example.com (where example.com is one of your normal domains) and get valid certificates for it. (In the case where you don’t want to expose your local hostnames you can also use bla-testing.example.com and get a wildcard cert for *.example.com. Although ultimately I’d say you just shouldn’t consider hostnames to be a secret.)

okket 9y ago
This is IMHO a very good practice and it will be even easier with the upcoming wildcard certificates from Let's Encrypt: https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html https://letsencrypt.org/2017/07/06/wildcard-certificates-com...
user5994461 9y ago
Companies run their own CA. They can generate as many certificates for internal domains as they want.
- hannob 9y ago
  Some companies do, many don't. I don't recommend running your own CA unless you have a very good reason to do so. It's complicated and it introduces additional security risks.
  - ehPReth 9y ago
    If one absolutely must regardless please use name/IP constraints! Client support isn't super awesome from what I understand but it's much better than having an unconstrained root ('keys to the internet') on >1 client - especially if you can't go the nines to protect said key.
    - bandrami 9y ago
      Wow, you guys have very different use cases from me. We do all internal authentication through server and client certificates. I'm still astounded that people seem to want a third party to participate in internal trust relationships, which seems just like a really bad idea to me.
      - detaro 9y ago
        They don't want a third party in internal trust relationships, but they want to avoid their internal trust being used to attack their communications with the outside even more. Locally added CA certs override even features such as key pinning, so if your local CA gets compromised it can be used to MITM everything. Not everyone trusts themselves to run a CA safely enough, or to make it properly available to developers.
  - bandrami 9y ago
    What? No; that's ridiculous. Running an internal CA is absolutely the right thing to do in almost any situation. Why on earth would you let a third party insert itself into your internal trust relationships?
    - user5994461 9y ago
      Yes, every company should have an internal trusted CA. I have no idea why there are people arguing against that.
      - ithkuil 9y ago
        Unfortunately it's not possible to limit the ability of that CA to create valid certificates for any arbitrary domain, at least not on all platforms, see https://bugs.chromium.org/p/chromium/issues/detail?id=407093 https://bugs.chromium.org/p/chromium/issues/detail?id=407093
        bandrami 9y ago
        And? What's the problem there?
        ithkuil 9y ago
        if you install a company internal CA, a rogue syadmin can create perfectly valid certificates for any domain,.including your bank's
        bandrami 9y ago
        Which is a perfect example of why you shouldn't use work equipment for personal traffic.
        ithkuil 9y ago
        Or, you are the CEO/CFO/whatever and don't want syadmins of one particular department to compromise your access to your company's bank account. I think you're oversimplifying. There are other scenarios you can imagine where it's not a good idea to let one security domain bleed into another.
lewisl9029 9y ago
I've been wanting to experiment with something like this for my own dev environments for a while, and have been eagerly awaiting wildcard cert support from Let's Encrypt. One thing I'm not quite sure about is if this means we need to be using the same wildcard cert for both dev and prod? I don't suppose the cert can be considered valid by the browser if otherwise? If that's the case, I'm wondering if there are any best practices around securely distributing valid production certificates to dev machines across a team and keeping them up-to-date with Let's Encrypt's auto renewing mechanism? Ideally in a way that's transparent to each individual developer? I'm guessing committing them directly into a repo is probably a bad idea, especially for open source projects.
- blfr 9y ago
  You can have more than one certificate for the same names but both would need to be valid. If the testing one leaks, someone can impersonate your production service.
  - ryanbrunner 9y ago
    To go further on this though, wildcards usually only allow one "level" of wildcarding. so if you had a wildcard cert for *.internal.domain.com no one could use it to impersonate www.domain.com (which is good, you should consider a cert that every developer has on their machine not trustworthy)
    - lewisl9029 9y ago
      Thanks for the clarifications. This is all starting to make a lot more sense now. Though I'm still curious how people usually distribute a cert like that internally and update it to keep it in sync with Let's Encrypt automatic renewal mechanism? As far as I understand, Let's Encrypt requires a public facing web server on the matching domain to renew certificates, so we'd have to actually set up a server solely for the purpose of certificate renewal on a 2-levels deep subdomain, expose it to the public internet, and then propagate the updated certs from that server into every dev machine every time a renewal is triggered? It sounds like there's little security risk with this approach as long as we use a wildcard cert at least 2-levels deep as you've described, as we don't have to trust this cert for real production traffic at the root domain. But I'm still wondering if there's some tooling I could adopt to streamline this process a bit? Or should I just bite the bullet and script it all myself?
jpalomaki 9y ago
localhost.mydomain.com pointing to 127.0.0.1 is quite handy for development.
- k__ 9y ago
  haha, nice trick. So the certs for *.mydomain.com will keep working, yes?
  - ComputerGuru 9y ago
    Yes. There’s nothing special about localhost besides the fact that’s aliases to 127.0.0.1 in the hosts file.
bandrami 9y ago
Why on earth would you want a third party CA to verify your own identity to you? What's the point? Just run an internal CA. For that matter a third party CA is worse, since it's an additional element in the trust chain.
- djsumdog 9y ago
  Exactly. You can run your own ACME compatible server internally and auto issue internal certs just like LetsEncrypt does. Then just put the company CA on your base Windows/mac images or policy, and create debs/rpms for your Linux devs/admins.
  - mnx 9y ago
    This is all nice and great when you have 100s, or even just 10s of developers, but is my team of 3 really supposed to do all that?
    - bandrami 9y ago
      I mean, yes? LibreSSL is pretty easy to use. An ACME server is even easier to use. And avoiding an external certificate authority means you can avoid most of the problems that exist in the worldwide PKI to begin with. If you have an ACME-compatible server you just set up an ansible script to deploy the certs for you (I think they even provide one); it's a one-time cost of a day or so, and if your sysadmin can't set it up you've got bigger problems.
    - corford 9y ago
      Honestly, I'd only go to the effort of mimicking Letsencrypt internally if you are already using their service for prod and wanted to keep your dev environment very close to this. Here's a gist you can follow if you'd like to do things the old fashioned way (i.e. create your own Root Certificate Authority, create a Sub-Root Authority and use that to sign internal certificates): https://gist.github.com/corford/9a206664bb8278c8243821d236665d94 https://gist.github.com/corford/9a206664bb8278c8243821d23666... It's 99% copy & pasteable (doesn't assume any existing openssl.conf) and should give you decent compatibility and future proofed security. Just remember to keep the root CA safe and only use the sub-ca for signing certs.
paulddraper 9y ago
I recommend *.dev.example.com Distributing your private SSL certificate to everyone in the company is a bad idea.

by hannob 9y ago

okket 9y ago

This is IMHO a very good practice and it will be even easier with the upcoming wildcard certificates from Let's Encrypt: https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html https://letsencrypt.org/2017/07/06/wildcard-certificates-com...

user5994461 9y ago

Companies run their own CA. They can generate as many certificates for internal domains as they want.

hannob 9y ago
Some companies do, many don't. I don't recommend running your own CA unless you have a very good reason to do so. It's complicated and it introduces additional security risks.
- ehPReth 9y ago
  If one absolutely must regardless please use name/IP constraints! Client support isn't super awesome from what I understand but it's much better than having an unconstrained root ('keys to the internet') on >1 client - especially if you can't go the nines to protect said key.
  - bandrami 9y ago
    Wow, you guys have very different use cases from me. We do all internal authentication through server and client certificates. I'm still astounded that people seem to want a third party to participate in internal trust relationships, which seems just like a really bad idea to me.
    - detaro 9y ago
      They don't want a third party in internal trust relationships, but they want to avoid their internal trust being used to attack their communications with the outside even more. Locally added CA certs override even features such as key pinning, so if your local CA gets compromised it can be used to MITM everything. Not everyone trusts themselves to run a CA safely enough, or to make it properly available to developers.
- bandrami 9y ago
  What? No; that's ridiculous. Running an internal CA is absolutely the right thing to do in almost any situation. Why on earth would you let a third party insert itself into your internal trust relationships?
  - user5994461 9y ago
    Yes, every company should have an internal trusted CA. I have no idea why there are people arguing against that.
    - ithkuil 9y ago
      Unfortunately it's not possible to limit the ability of that CA to create valid certificates for any arbitrary domain, at least not on all platforms, see https://bugs.chromium.org/p/chromium/issues/detail?id=407093 https://bugs.chromium.org/p/chromium/issues/detail?id=407093
      - bandrami 9y ago
        And? What's the problem there?
        ithkuil 9y ago
        if you install a company internal CA, a rogue syadmin can create perfectly valid certificates for any domain,.including your bank's
        bandrami 9y ago
        Which is a perfect example of why you shouldn't use work equipment for personal traffic.
        ithkuil 9y ago
        Or, you are the CEO/CFO/whatever and don't want syadmins of one particular department to compromise your access to your company's bank account. I think you're oversimplifying. There are other scenarios you can imagine where it's not a good idea to let one security domain bleed into another.

lewisl9029 9y ago

I've been wanting to experiment with something like this for my own dev environments for a while, and have been eagerly awaiting wildcard cert support from Let's Encrypt. One thing I'm not quite sure about is if this means we need to be using the same wildcard cert for both dev and prod? I don't suppose the cert can be considered valid by the browser if otherwise? If that's the case, I'm wondering if there are any best practices around securely distributing valid production certificates to dev machines across a team and keeping them up-to-date with Let's Encrypt's auto renewing mechanism? Ideally in a way that's transparent to each individual developer? I'm guessing committing them directly into a repo is probably a bad idea, especially for open source projects.

blfr 9y ago
You can have more than one certificate for the same names but both would need to be valid. If the testing one leaks, someone can impersonate your production service.
- ryanbrunner 9y ago
  To go further on this though, wildcards usually only allow one "level" of wildcarding. so if you had a wildcard cert for *.internal.domain.com no one could use it to impersonate www.domain.com (which is good, you should consider a cert that every developer has on their machine not trustworthy)
  - lewisl9029 9y ago
    Thanks for the clarifications. This is all starting to make a lot more sense now. Though I'm still curious how people usually distribute a cert like that internally and update it to keep it in sync with Let's Encrypt automatic renewal mechanism? As far as I understand, Let's Encrypt requires a public facing web server on the matching domain to renew certificates, so we'd have to actually set up a server solely for the purpose of certificate renewal on a 2-levels deep subdomain, expose it to the public internet, and then propagate the updated certs from that server into every dev machine every time a renewal is triggered? It sounds like there's little security risk with this approach as long as we use a wildcard cert at least 2-levels deep as you've described, as we don't have to trust this cert for real production traffic at the root domain. But I'm still wondering if there's some tooling I could adopt to streamline this process a bit? Or should I just bite the bullet and script it all myself?

jpalomaki 9y ago

localhost.mydomain.com pointing to 127.0.0.1 is quite handy for development.

k__ 9y ago
haha, nice trick. So the certs for *.mydomain.com will keep working, yes?
- ComputerGuru 9y ago
  Yes. There’s nothing special about localhost besides the fact that’s aliases to 127.0.0.1 in the hosts file.

bandrami 9y ago

Why on earth would you want a third party CA to verify your own identity to you? What's the point? Just run an internal CA. For that matter a third party CA is worse, since it's an additional element in the trust chain.

djsumdog 9y ago
Exactly. You can run your own ACME compatible server internally and auto issue internal certs just like LetsEncrypt does. Then just put the company CA on your base Windows/mac images or policy, and create debs/rpms for your Linux devs/admins.
- mnx 9y ago
  This is all nice and great when you have 100s, or even just 10s of developers, but is my team of 3 really supposed to do all that?
  - bandrami 9y ago
    I mean, yes? LibreSSL is pretty easy to use. An ACME server is even easier to use. And avoiding an external certificate authority means you can avoid most of the problems that exist in the worldwide PKI to begin with. If you have an ACME-compatible server you just set up an ansible script to deploy the certs for you (I think they even provide one); it's a one-time cost of a day or so, and if your sysadmin can't set it up you've got bigger problems.
  - corford 9y ago
    Honestly, I'd only go to the effort of mimicking Letsencrypt internally if you are already using their service for prod and wanted to keep your dev environment very close to this. Here's a gist you can follow if you'd like to do things the old fashioned way (i.e. create your own Root Certificate Authority, create a Sub-Root Authority and use that to sign internal certificates): https://gist.github.com/corford/9a206664bb8278c8243821d236665d94 https://gist.github.com/corford/9a206664bb8278c8243821d23666... It's 99% copy & pasteable (doesn't assume any existing openssl.conf) and should give you decent compatibility and future proofed security. Just remember to keep the root CA safe and only use the sub-ca for signing certs.

paulddraper 9y ago

I recommend *.dev.example.com Distributing your private SSL certificate to everyone in the company is a bad idea.