5 ms·

For a long time I was all fussy about having to create a security exception for self-signed certificates. One day I realized I was acting insane, as if there wa

For a long time I was all fussy about having to create a security exception for self-signed certificates. One day I realized I was acting insane, as if there was some glorious principle involved. There isn't. I trust my own (or coworkers) certificates. It's a dev site for heavens sake. Ever since, ssh-keygen all the way.

savolai 5y ago
It appears to me the issue is browser warning dialogs that imply it is always very dangerous. There should be either more context explained in those dialogs or a recognition of/mode for sites that are supposed to be self signed.
- dboreham 5y ago
  There is a long history to this. The original browser warnings were along the lines of your suggestion. Then it was discovered that regular users just clicked through the warning when an attacker MITM'ed their bank. There followed decades of making the warning ever more scary sounding and ever more difficult to bypass.
  - savolai 5y ago
    Where does responsibility lie here? Is there a mechanism for users to state trust towards their org's sysadmin instead of a global authority? If there isn't, what is the problem preventing this in the long history you mention?
- ThermalCube 5y ago
  (Untested idea) I'd suggest creating your own Root CA with an expire-date far in the future. Install it's public key as a trusted certificate and all derived certificates should not prompt any issues anymore
  - spyke112 5y ago
    Please don't. I've been in orgs doing this and it sucks. There seems to just be to many edge cases, and to many custom scripts for setup.
  - coding_unit_1 5y ago
    That's not untested insofar as that's how I've always seen self-signed certs managed in an org.
  - PinguTS 5y ago
    Then far in the future, when your own Root CA expires, then there comes all the trouble to update all the services/devices to trust the new Root CA. This becomes a nightmare, when the original admin in the org is gone long times ago.
  - tqwhite 5y ago
    I did this on my workstation. I used it for a short while. Then I realized that I was actually putting a thing into the world that circumvents the entire security infrastructure of the world. Then I needed to do it for a server. Local only. Never production. Then I thought, WTF am I doing?. I realized that I was making computers that would circumvent the world's security apparatus. Of course it won't hurt if I make no errors of practice or judgement but, am I really smart enough to handle highly radioactive material. I ripped it all out. It makes me shudder thinking about it.
tyingq 5y ago
It can be tricky to get self-signed certificates put into all the various places where they need to be. OS level certificate stores, browsers, mobile devices, curl, python/requests, VPN clients, etc. There's always some weird exception case.
- ninkendo 5y ago
  Yeah, I think OP probably mostly does web development through the browser, where there’s just one trust store to worry about. As soon as you need some automation involving backend services or even just curl and some scripts, this gets tougher. (And please please don’t use `curl -k` to disable checks… if such scripts accidentally make their way to production, you may as well not use TLS at all.)
  - BrandoElFollito 5y ago
    About the -k: why? A certificate has two main functions: identity of the server and encryption. Not checking the chain leaves you with encryption, which is likely what your need. A self-signed certificate is as good as any other when it comes to encryption.
    - ninkendo 5y ago
      If you're in a situation where encryption matters to you, you're in a situation where the identity of the remote end ought to matter to you as well. If someone's able to snoop the traffic between you and the remote end, it's dangerous to assume they won't also be able to MITM you.
      - BrandoElFollito 5y ago
        A self-signed certificate provides an identity the same way as a CA-signed one. The only difference is that it is in a CA chain. You may trust the CA enough to not check further, but if you want to make sure that the endpoint you are talking with is the one you expect, you should check the identity of the certificate on the server. And it is the same for a self-signed certificate as from a CA-issued one.

savolai 5y ago

It appears to me the issue is browser warning dialogs that imply it is always very dangerous. There should be either more context explained in those dialogs or a recognition of/mode for sites that are supposed to be self signed.

dboreham 5y ago
There is a long history to this. The original browser warnings were along the lines of your suggestion. Then it was discovered that regular users just clicked through the warning when an attacker MITM'ed their bank. There followed decades of making the warning ever more scary sounding and ever more difficult to bypass.
- savolai 5y ago
  Where does responsibility lie here? Is there a mechanism for users to state trust towards their org's sysadmin instead of a global authority? If there isn't, what is the problem preventing this in the long history you mention?
ThermalCube 5y ago
(Untested idea) I'd suggest creating your own Root CA with an expire-date far in the future. Install it's public key as a trusted certificate and all derived certificates should not prompt any issues anymore
- spyke112 5y ago
  Please don't. I've been in orgs doing this and it sucks. There seems to just be to many edge cases, and to many custom scripts for setup.
- coding_unit_1 5y ago
  That's not untested insofar as that's how I've always seen self-signed certs managed in an org.
- PinguTS 5y ago
  Then far in the future, when your own Root CA expires, then there comes all the trouble to update all the services/devices to trust the new Root CA. This becomes a nightmare, when the original admin in the org is gone long times ago.
- tqwhite 5y ago
  I did this on my workstation. I used it for a short while. Then I realized that I was actually putting a thing into the world that circumvents the entire security infrastructure of the world. Then I needed to do it for a server. Local only. Never production. Then I thought, WTF am I doing?. I realized that I was making computers that would circumvent the world's security apparatus. Of course it won't hurt if I make no errors of practice or judgement but, am I really smart enough to handle highly radioactive material. I ripped it all out. It makes me shudder thinking about it.

tyingq 5y ago

It can be tricky to get self-signed certificates put into all the various places where they need to be. OS level certificate stores, browsers, mobile devices, curl, python/requests, VPN clients, etc. There's always some weird exception case.

ninkendo 5y ago
Yeah, I think OP probably mostly does web development through the browser, where there’s just one trust store to worry about. As soon as you need some automation involving backend services or even just curl and some scripts, this gets tougher. (And please please don’t use `curl -k` to disable checks… if such scripts accidentally make their way to production, you may as well not use TLS at all.)
- BrandoElFollito 5y ago
  About the -k: why? A certificate has two main functions: identity of the server and encryption. Not checking the chain leaves you with encryption, which is likely what your need. A self-signed certificate is as good as any other when it comes to encryption.
  - ninkendo 5y ago
    If you're in a situation where encryption matters to you, you're in a situation where the identity of the remote end ought to matter to you as well. If someone's able to snoop the traffic between you and the remote end, it's dangerous to assume they won't also be able to MITM you.
    - BrandoElFollito 5y ago
      A self-signed certificate provides an identity the same way as a CA-signed one. The only difference is that it is in a CA chain. You may trust the CA enough to not check further, but if you want to make sure that the endpoint you are talking with is the one you expect, you should check the identity of the certificate on the server. And it is the same for a self-signed certificate as from a CA-issued one.