I use a SSL in my main domain, that is the one my clients access.
However, I have a second domain with the same content (including login credentials) that I use only for test and development.
Should I secure this test domain too?
7
-
9Why wouldn't you secure it? What is stopping you?– schroeder ♦Commented Mar 13, 2017 at 13:57
-
3The price of the SSL certificate.– carlaCommented Mar 13, 2017 at 13:59
-
34There are many free ways to provide SSL. Self-signed certificates, and LetsEncrypt.– schroeder ♦Commented Mar 13, 2017 at 14:01
-
21If it has the same content, why is it a test domain? Does this mean that if a customer signs in your test domain from a public wi-fi, an attacker could obtain valid credentials that can be used for the production domain?– lorenzogCommented Mar 13, 2017 at 14:34
-
31WOW. Please don't use live data (ESPECIALLY CREDENTIALS) in your test application as your live one...– MilneyCommented Mar 13, 2017 at 16:16
|
Show 2 more comments
6 Answers
Yes, you should. You might need to test if e.g. a particular request works over HTTPS, but testing on a production system is a bad idea (the production system should remain stable), and your test system should match the production system as closely as possible. Secondly, if you're sharing the login details between domains, why shouldn't the test domain be secured as well?
If the price of the certificate is a problem, what you can do is:
- Get a free cert from Let's Encrypt.
- Use a self-signed cert.
- Set up your own internal certificate authority for the test domain (probably the best option).
-
22The test system should be as close to the live system as possible with the exception of the data in use (which should be closely modelled after live but mock data). Otherwise you aren't testing. The number of times I've seen systems fail when deployed due to differences between the live and QA platform.......– pwdstCommented Mar 13, 2017 at 17:04
-
Good catch, @pwdst. I'll rephrase that sentence a bit (my unstated point was that the production system should remain stable).– user81469Commented Mar 13, 2017 at 18:24
-
3Can someone elaborate as to why the last option is the best? What advantage is there over using a certificate from Let's Encrypt? (I don't doubt you, just curious as this isn't my area of expertise.) Commented Mar 14, 2017 at 21:27
-
3@Josh1billion setting up an internal CA means you have a trusted root cert that can issue certs for your internal servers. If all your test clients trust this CA, you can issue a new cert for a particular server, and your clients will automatically trust it. This would probably be quicker than waiting for an external CA, and you wouldn't have to manually propagate a new self-signed cert to all your test clients.– user81469Commented Mar 14, 2017 at 21:36
-
2@Josh1billion: You don't need Internet connectivity to get a new certificate if you are the authority (allowing working offline, ...); you can generate certificates with many quirks (to validate your SSL stack/application) if you are the authority; you can generate many different certificates with no rate limitings (not sure it applies); ... freedom and control, in short. Of course, for a domain external users will need to access, you need a trusted CA. Commented Mar 15, 2017 at 7:46
I have a second domain with the same content (including login credentials) that I use only for test and development.
If the second domain provides the same content and has the same login credentials and is accessible from the internet too then there is no reason that it should not get same protection (i.e. SSL) as the first domain.
answered Mar 13, 2017 at 14:00
Not only should you use SSL for your test domains, but you need to if you want to enable security features like HSTS Preloading.
-
I think that HSTS Preloading is not much of an issue here; the test server will probably have these details changing regularly anyway. Commented Mar 13, 2017 at 18:44
-
HSTS preloading mandates all sub domains load with HTTPS too, and I think this answer author assumed the test sites are subdomains of main one.– AKSCommented Mar 14, 2017 at 20:35
-
You should. That is the short answer.
In the longer answer, you would be surprised to know how many times security vulnerabilities happen from internal users of an organisation. e.g, If your test environment has admin credentials, then a unprotected transport layer mean someone from your organisation (who is not an authorised admin) can potentially sniff and get the admin credentials - which you don't want.
If certificate cost is an issue, you can always have self signed certificate issued. But you should make sure this signing authority (whoever is generating this internal certificate for you) is installed as trusted CA on the testing desktops. Otherwise your browser might throw error that this certificate is signed by someone untrusted. If you run 'certmgr.msc' in windows, you can see the trusted CAs for any particular machine.
Yes...testing is only valid if it simulates the production environment, including how it performs over https. Wildcard certs are fairly cheap, so just put the test domain under a subdomain. You test domain should probably not be public facing though unless the client requires access to it from random IP's, otherwise lock it down to your own IP range in the virtualhost or firewall. Plus its a good way to make sure all the content on your website is available over https.
You definitely need it for testing purposes. We have had situations where behavior of our system was different on SSL from insecure connection.
For security purposes it is not required, since you can move your test environments behind VPN.
-
3Your first line is covered by the other answers, your last line is very poorly worded - What you mean to say is that, yes, you still need to secure the site, but you could do it with a VPN and not an SSL connection. But that suggestion makes a lot of assumptions on the design, capabilities, and development intent of the OP's situation.– schroeder ♦Commented Mar 14, 2017 at 11:32