29

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?

  • 9
    Why wouldn't you secure it? What is stopping you? – schroeder Mar 13 '17 at 13:57
  • 3
    The price of the SSL certificate. – carla Mar 13 '17 at 13:59
  • 34
    There are many free ways to provide SSL. Self-signed certificates, and LetsEncrypt. – schroeder Mar 13 '17 at 14:01
  • 21
    If 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? – lorenzog Mar 13 '17 at 14:34
  • 31
    WOW. Please don't use live data (ESPECIALLY CREDENTIALS) in your test application as your live one... – Milney Mar 13 '17 at 16:16
67

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).
  • 22
    The 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....... – pwdst Mar 13 '17 at 17:04
  • Good catch, @pwdst. I'll rephrase that sentence a bit (my unstated point was that the production system should remain stable). – Philip Rowlands Mar 13 '17 at 18:24
  • 3
    Can 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.) – Josh1billion Mar 14 '17 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. – Philip Rowlands Mar 14 '17 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. – Matthieu M. Mar 15 '17 at 7:46
12

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.

4

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. – wizzwizz4 Mar 13 '17 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. – Ayesh K Mar 14 '17 at 20:35
  • @AyeshK That is correct. – nasukkin Mar 14 '17 at 20:57
3

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.

2

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.

1

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.

  • 3
    Your 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 Mar 14 '17 at 11:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.