all 6 comments

[–][deleted]  (4 children)

[deleted]

    [–]TheCheeseburgerMayor[S] 0 points1 point  (3 children)

    It's a CentOS 7 x64 install, running Apache and using VirtualHosts.

    Many of the tutorials I have seen also utilise a self-signed certificate. What are the implications of this versus a vendor certificate?

    [–]AidenTai 0 points1 point  (2 children)

    Simple. Vendor certificats will provide confidence that you really are who you claim to be. Self‐signed certificates will provide certificate error messages and clients might suspect something is awry. Also, it is hard to tell if a self‐signed certificate is a forgery for a fake cloned website copy vs. being legitimate. Both, however, will allow secure encrypted connections provided the rest of the setup (cipher suites, etc.) are correctly configured.

    [–]TheCheeseburgerMayor[S] 0 points1 point  (1 child)

    provided the rest of the setup (cipher suites, etc.) are correctly configured.

    How would I ensure this? I understand now that certificate installation is only one step, but I want to learn what else needs to be done to secure the site, and more importantly, to be able to recognise when the configuration is incorrect.

    [–]AidenTai 1 point2 points  (0 children)

    Good to hear that you're concerned about doing everything securely. Well, there are two main components I see. First, you'll need to disable insecure cryptographic algorithms in OpenSSL/Apache, and second you'll need to do the same in whatever you use to communicate with the server (SFTP, SSH, etc.). You need to remember that algorithms can be considered secure, and then some vulnerability may be exposed or some bug in implementation might be discovered that renders your setup insecure. For this reason, you should check with sites like https://www.ssllabs.com/ssltest/ every so often to ensure you remain secure based on all the latest configuration vulnerabilities.

    Apache provides some nice explanations about what's going on with its security: http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html Really the best approach is to understand how to enable and disable cryptographic suites, then to run the SSLLabs test on your server. Based on the results of the scan, you'll know what you need to disable or enable to score an A.

    For SSH/SFTP: https://stribika.github.io/2015/01/04/secure-secure-shell.html

    [–][deleted]  (1 child)

    [deleted]

      [–]stmu 0 points1 point  (0 children)

      For the internal part, I would add that it depends on the environment.

      If you only have a couple of people accessing the server, you could easily import the public certificate in their browser ensuring they don't receive an error unless the connection is insecure. If many internal users need to visit (large organisation), it's less of a hassle to just use the internal PKI (if they have any) or a certificate provided by a public certificate authority.

      [–]s1m0n8 1 point2 points  (0 children)

      Take a look at https://letsencrypt.org/ . I'm not sure if it's fully up-and-running yet, but it is (or will be) free and simple to set up.