Securing SSL certificate and private key in apache server? - ssl

Normally apache web sever needs SSL certificates to load from file. This makes certificates to store in apache webserver disk. Is this considered as security risk ? Is there set of guidelines to secure these certificates ? I have client which thinks this is a risk and I want to prove him otherwise or give a solution. So far i have not come across with good solution. Even we use solution like HashiCorp vault still the certificates needs to be given to apache server disk. Any suggestions or guidelines to secure this ssl certificate or any best practices for storing ssl certificate in secure manner is very helpful.

Approach: 1(Older) Maintain the certificates in disk and secure the directory which holds the certificates. Following steps is an option to secure certificates in disk.
Change permission of certificates directory to '700' to restrict other users of server can not access(for read/write/delete) the files
Change permission of apache bin and conf directories which holds the path for certificates and start up scripts. This also to be restricted from other users
Disable sftp & scp for apache user to avoid sending any file outside the server
Approach:2 Integration with HSM Hardware to generate and store SSL certificates and improve performance by offloading encryption and decryption through HSM.
There are few market vendors available in market to integrate Apache Web server with HSM like Luna HSM by Thales (https://cpl.thalesgroup.com/resources/encryption/apache-http-server-luna-integration-guide), nCipher HSM, AWS CloudHSM, etc.

Private key is what you need to protect; not certificates. Best way to protect a Private key is by using a Hardware device such as a Smart-Card, USB Token or a Hardware Security Module (HSM).
A digital certificate contains the public key which is mostly distributed publicly. Even if someone gets it, there's hardly anything they could do with it.

Related

Terraform Init/apply/destroy - SSL Connection Problems

our company proxy brokes the SSL Connections and the proxy use our own CA.
So i have always tell the applications i use (RubyGems, Python Pip, Azure CLI ...) to use our company CA Certificate.
Does anyone know, how i can use our CA Certificate with a local Terraform installation?
Is the CA deployed to your OS's certificate store or can you import it? If so, Terraform (and probably other tools) should just be able to work with a proxy like this with no other configuration. If you need some further direction, tell us what operating system and how you typically access you have to the CA.
Edit:
#Kreikeneka have you have the certain the location CentOS expects to import into the store. There is a command you need to run that actually imports it update-ca-trust. Have you run this? If the cert is being used for SSL and you just need to trust it when going through your proxy, that is all you should need to do. You shouldn't need to tell your tools (Terraform, PIP, etc) to trust it for SSL with the proxy. If the cert is imported into your certificate store, it should be passively usable from any connection on from the machine from any process.
If you are using the cert for client authentication to the proxy then just trusting the cert by placing it in the certificate store probably won't work.
I'm not clear from your comments if you need the cert for SSL or for client authentication to the proxy. Check with your IT what it is really used for if you aren't sure and get back to us.
As of CentOS 6+, there is a tool for this. Per this guide,
certificates can be installed first by enabling the system shared CA
store:
update-ca-trust enable
Then placing the certificates to trust as CA's
in /etc/pki/ca-trust/source/anchors/ for high priority
(non-overridable), or /usr/share/pki/ca-trust-source/ (lower priority,
overridable), and finally updating the system store with:
update-ca-trust extract
Et voila, system tools will now trust those
certificates when making secure connections!
Source:
https://serverfault.com/questions/511812/how-does-one-install-a-custom-ca-certificate-on-centos

Local network HTTPS with IP address

I have a small REST server running on a local network, with a bunch of client applications connected (via IP address).
I want to secure this traffic so that access tokens cannot be sniffed.
According to This answer I can create a self signed cert. using an IP (although not common). If i go down this route (assuming no physical access to the server box itself) is this secure?
Yes. It is as secure as CA-signed certificate as long as users always install the correct certificate. (Make sure the the certificate is distributed securely.)
If distributing it securely seems too much trouble, then you may see answers here and consider using certificate issued by letsencrypt.org if you can.

Self signed certificate for machine to machine https connection

I need to set up https communication between a Tomcat application server and a back end system. The web server hosts a public website, so is in a DMZ.
My question is if there any advantage in using official CA certificates, over using self signed certificates in this situation (machine to machine communication)?
I keep hearing self signed certificates should not be used on production systems, but I'm not sure I understand why (for machine to machine communication).
The risk lies in how effective the defenses protecting the hosts in question are, including the network connection between them. Given that weaknesses and exploits are being found all the time, it is reasonable to say there could be issues with self-signed certificates used in a production environment - which includes hosts in a DMZ.
Here's the reason: man-in-the-middle. In short, if either host - or the network between them - becomes compromised, then the traffic between them will still be encrypted, but because the certificate is self-signed, a man-in-the-middle (aka "MITM") would be able to introduce a transparent proxy using a self-signed cert, which will be trusted by both sides.
If instead your hosts use a public CA, then the MITM approach cannot work.
If the annual $15-50 investment per host is more costly than the information on and between them - including what could be on them (e.g., compromised, serving malware), then the choice is simple: don't worry about buying certs. Otherwise, it's important to look into them.
The comment by Adam Hupp on this webpage provides a good, simple scenario:
http://www.vedetta.com/self-signed-ssl-certificates-vs-commercial-ssl-certificates-how-mozilla-is-killing-self-signed-certificates
And here's a more fleshed out description of the risk:
http://blog.ivanristic.com/2008/07/vast-numbers-of.html
And finally a balanced look at the two scenarios, though this article only considers self-signed OK when there is a fully-functional, properly protected and implemented Certificate Authority server installed:
http://www.networkworld.com/news/tech/2012/021512-ssl-certificates-256189.html
I see no advantage in using official certificates for this task - besides the fact that your marketing dept. could claim your infrastructure is "100% certified by $CA". Encryption algorithm/strength and cert duration can be the same, depending on how you configure it.
The recommendations you hear probably focus on the far more common usage of HTTPS for communication with browsers, which nowadays complain about self signed certs. For data transfer between servers, I think it's good practice to encrypt traffic the way you plan on doing it!

distributed PKI Certificate handling- making it user friendly

I have a Server and N number of clients installed on different hosts. Each host has its self-signed certificate generated during install. The client authentication is turned ON at this point. Which means they can't communicate to each other until these certs are properly imported as described below.
Now, the server needs to import all the clients' certificates. So do all the clients from this single server. This part is really not user friendly to do it during install as either client or the server can be installed independent of each other any time.
What is the better way to import certs between clients and server without the user having to perform some kind of out-of-band manual steps?
PS: The PKI tool I am using can only import/export certificates on a local machine only. Assume I can't change this tool at this time.
In general, this is one of the problems with PKI. It is a pain to securely distribute certificates in an automated fashion.
In an Active Directory domain environment you already have a Kerberos trust in place. Therefore you can use group policy to securely distribute certficates automatically. Don't know if that would apply to you because you haven't given information about your environment/OS etc.

SSL certificate migration from one server to another

What's necessary to migrate valid SSL certificate from one server and service provider to another?
In some cases it may be simply a matter of copying the keys to and changing apache configuration on the new server.
For example:
http://www.digicert.com/ssl-support/apache-ssl-export.htm
Some certificate authorities may tie an SSL certificate to a specific server.
Essentially, you export SSL certificates from the server that they are currently installed on, move SSL certificates to the new server, and then import SSL certificates on the new server. But this only really only applies if you are sticking with the same certificate authority ("provider")... which it sounds by your question that you are not.
Keep in mind that even if you stick with the same provider, many require that you purchase a "server license" for each server that you install an SSL certificate to, even if it uses the same private key. And speaking of private keys, it is slightly less secure to copy the SSL certificate and use the same private key on a different server. If an attacker breaks into one server and gets the private key, he will be able to listen in on the connections that other servers are making.
So my advice to you since you want to switch providers is just purchase a new one all together with the new provider once you move to the new server... But maybe I'm misunderstanding your question.
First determine if the device installed with the certs are storing the private key in hardware/software. In most today's servers, they are in software *.key files (e.g. web server SSL).
To be found near the key files are the certificate and perhaps even CSR. Moving these files to another server is generally allowed (Considering the destination server will have the same hostname) and hence keeping the same CA. Most CAs have no concern to customers who does that.
But if you are just looking to switch the service provider from one to another, simply ask current CA to 'revoke' the cert. Then start with the new Cert buying process with the new CA.