5 ms·

I agree with everything you say. But are you telling me that each developer should do this for their personal webpage project just because Chrome might decide

by pilif 8y ago

I agree with everything you say. But are you telling me that each developer should do this for their personal webpage project just because Chrome might decide to put HTTP-only pages behind a modal dialog?

tialaramex 8y ago
Individual developers can often test with localhost (use the numeric 127.0.0.1 or ::1 for best browser compatibility). All the Browser Vendors are agreed that although http://127.0.0.1/ http://127.0.0.1/ isn't HTTPS, it is a secure context, all the fancy new secure-only features of web pages should work (if any don't that's a browser bug) and so on, there is no security interstitial and so on. If you're a bit bigger, so that you're needing to put webpage projects on a separate machine, so maybe QA can try it, or you can run a demo, you can and should set aside one or more chunks of public DNS hierarchy for the test systems, for example a cert for *.test.example.com can allow a number of test systems at Example Inc to do HTTPS. If you're happy to pay a commercial CA they'll mint such a certificate for fair price upon proof you control example.com. If you want to use Let's Encrypt, they'll need you to have records for test.example.com in public DNS to run proof of control automatically. Provisioning the private key and copies of (periodically updated) certificates to the test boxes is not exactly a difficult problem for a working test environment. Only if you (perhaps out of paranoia) refuse to do that, should you try what I suggested with a private CA hierarchy for web pages. If you're building something quite different (not TLS, or genuinely not on the Internet, although what the point of things other than the Internet is I'm not sure) then you can and should roll your own PKI, but that's a huge under-taking, you should already have hired at least one person who knows MORE about this than me or you're already in deep trouble.

by pilif 8y ago

tialaramex 8y ago

Individual developers can often test with localhost (use the numeric 127.0.0.1 or ::1 for best browser compatibility). All the Browser Vendors are agreed that although http://127.0.0.1/ http://127.0.0.1/ isn't HTTPS, it is a secure context, all the fancy new secure-only features of web pages should work (if any don't that's a browser bug) and so on, there is no security interstitial and so on. If you're a bit bigger, so that you're needing to put webpage projects on a separate machine, so maybe QA can try it, or you can run a demo, you can and should set aside one or more chunks of public DNS hierarchy for the test systems, for example a cert for *.test.example.com can allow a number of test systems at Example Inc to do HTTPS. If you're happy to pay a commercial CA they'll mint such a certificate for fair price upon proof you control example.com. If you want to use Let's Encrypt, they'll need you to have records for test.example.com in public DNS to run proof of control automatically. Provisioning the private key and copies of (periodically updated) certificates to the test boxes is not exactly a difficult problem for a working test environment. Only if you (perhaps out of paranoia) refuse to do that, should you try what I suggested with a private CA hierarchy for web pages. If you're building something quite different (not TLS, or genuinely not on the Internet, although what the point of things other than the Internet is I'm not sure) then you can and should roll your own PKI, but that's a huge under-taking, you should already have hired at least one person who knows MORE about this than me or you're already in deep trouble.