We're working on a TCP server that secures its communication with its clients using TLS/SSL.
Currently we are storing our public (.cer file) and private (password protected, private key included .p12) certificates in the Windows certificate store. We are going to increase the number of TCP servers soon and depending on the traffic we'll be adding more and more in time.
To facilitate the deployment process and periodic certificate change (or in case we detect some sort of intrusion) we plan to store both (private and public) certificates in the system's common MySQL database that is accessible by the TCP servers.
Is storing the .cer and password protected .p12 files in BLOB columns a bad idea from a security point of view?
P.S: I don't think it is very relevant but the TCP server is being developed in c#.
Skipping the security concerns, your language is PKE with native support for the windows store, you are going to have to roll your own (increase complexity) with this change. It would be better as part of the server start to update the Windows Store.
From a security point of view, you now have additional points where the encrypted key are accessible. Is you password secure enough? This is not a best practice and should be managed by the systems admin doing the install and updates. Lastly, this increase of complexity also increase the attack surface.
Related
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.
The widely acknowledged configuration of SSL for Apache is to point to the location of Certificate and private key.
Can we configure SSL without storing the private key in a file, rather by keeping it in memory?
You could use Keywhiz for this:
Keysync is a Keywhiz client that retrieves secrets from a Keywhiz
Server using mTLS with a client certificate and stores them in tmpfs.
Presenting secrets as files makes Keywhiz compatible with nearly all
software. Outside of Keywhiz administration, consumers of secrets only
have to know how to read a file.
Keysync stores all secrets in memory only (via tmpfs) and never
persists them to disk. If the server loses power, all secrets will be
safely removed from that server.
Keysync's design mitigates a Keywhiz Server outage, since all
necessary secrets are stored locally, and can be accessed even if
Keysync process is restarted. The full sync of secrets is only
necessary in the event of a server reboot.
I'm looking to configure wcf to transport data from one web server to another web server with exactly one service host and exactly one client.
Is there a simple security configuration available that does not require x509 certificates?
Additional info:
I may be looking for a simple configuration (message is okay) that could use a predetermined username / pw / enc, etc. I'd also like to avoid sending a password in cleartext.
If by "simple security configuration" you mean encrypting the transmissions between the end points, there's no simple, easy way without using x509 certificates, short of creating some kind of elaborate VPN connection point to point.
But using certificates with WCF doesn't have to be painful or expensive. Using message-level encryption (xml based) is easy enough to configure and get running, and since the communication is always between points "A" and "B", the obvious problems associate with using message encryption (distributing the certificates) isn't a problem at all.
The steps would be:
-Generate a self-signed x509 cert with public and private keys and copy to both servers
-Configure your clients and host to use message security
-install certs on both servers (plenty of documentation available, like this one)
-Configure your host and clients to find the certificates during startup
-run and test
After you've got everything running, you'd obviously replace your self-signed cert with a commercial version.
You didn't mention your platform. Are you on Windows? If so, you can use Windows credentials with message-level encryption and no need for certificates. Here is a step by step guide on how to do it.. Hope this helps!
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.
One of my friend is working on issue related to updating expired digital certificates.
He is working on Java application(Swings I guess), which has 4000 clients. All those need a digital certificate to connect to the application and this certificate expires every year.
At the end of year he needs to update the certificate credentials for all clients. Currently this is manual process, done by connecting to each of 4000 systems either locally or by remote connection.
He is got task to convert this process to be an automated process.
Normally the client-side certificate (used by authenticating the client on the server) needs to be passed to the client physically (on the carrier), otherwise, if the certificate is sent via electronic channels, there's a high risk of interception. But if secure connection is used, then the problem becomes less critical.
So the answer depends on how the client-side application is built. The easiest approach would be to add capabilities to refresh the certificate (before it expires) right from the application. The application would request fresh certificate from the server.
If no such capabilities are built-in and there's no way to add them, then the answer would depend on where the client-side application stores the certificate, used for authentication. If it's some file, then automating remote desktop connection using some automation tool would be the only choice.