I followed the RabbitMQ SSL guide meticulously.
https://www.rabbitmq.com/ssl.html
And it works, of course. But I've had to install the Certificate Authority on the computer running RabbitMQ server and on the PC connecting to the server.
What was not clear to me on the guide is what happens next. My self-created certificates are just for development. What do I do next to make this a production system?
Normally in production systems you have a internal CA maintained by
your organization. Get your certificates signed by the CA.
Also make sure to use TLS v1.2.
Related
Hostgator provides free Let's Encrypt SSL cert so I let my Comodo cert expire. Netbeans won't connect now and gives java.security.cert.certificateexpiredexception.
I'm in the process of renewing the comodo cert but wonder if there is a way to fix this. The plugin SSL Cert Exception in Netbeans did not fix this issue for me.
Netbeans does not want to connect to remote server because the comodo certificate expired. I get this error in the popup:
java.security.cert.certificateexpiredexception
It is not recognizing the Let's Encrypt certificate which is still valid that is also on the server.
This SSL issue did not go away when the new comodo cert was installed. But I was able to use FTP in Netbeans without TLS.
SSL issues appear to have been caching related, Hostgator have since cleared any applicable cache and issues with connecting via FTP on TLS have stopped.
I probably did not need to buy the new comodo cert to fix this issue. Sorry I don't have info on exactly which cache was cleared on the server, but maybe this is enough info to get someone who runs into this issue onto the right path.
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
Is it possible to store the client certificate for rabbitmq server in the windows certificate store?
I know that doing so in the c# client is supported, but haven't seen any mention of a similar option for the server itself.
the ssl_options in rabbit.config mention only using certificates stored on the file system.
Not at this time. Support for the Windows cert store would have to be added to Erlang itself.
In our environment,we often reinstall our machine with the same hostname.
So,everytime I sync the configuration vai puppet,SSL authentication will fail.
How can I totally disable SSL authentication?
The assumption that connections are authenticated and identified through trusted SSL certificates runs very deep in Puppet's core. There is no way to make Puppet run through unencrypted channels only.
Things you can try:
holding on to signed certificates and getting them back onto machines just when they are re-provisioned
creating a hook that will make the master revoke the old certificate when a machine is decommissioned/recommissioned
With the latter approach, the signing of fresh certificates will be eased considerably. You might even implement an autosigning scheme, although that is tricky to do in a secure fashion.
I have a thick client written in VB6 that connects to an Sql Server 2005 Database. I want to secure the connection by using SSL between the client and DB.
I've looked at these links for details on "how to" configure it.
http://msdn.microsoft.com/en-us/library/ms189067%28SQL.90%29.aspx
Question
If I want to buy an SSL certificate to use in this scenario, do I just buy the standard SSL certificate sold for websites? I would imagine so, but I want to make sure.
I guess SSL certificates are standard and can be utilized anywhere as long as the client and server know how to use that protocol.
But in case I do buy a standard SSL certificate, what do I mention as far as my website domain address etc? - Since I'm going to use it between thick VB6 client and SQL Server 2005, I wasn't clear how to go about this.
Is there any other (easier) way of securing the connection between a thick client and Sql Svr DB? My requirement is to only make the connection secure....it doesnt have to be SSL.
Thanks
Amit
You need to use a certificate trusted by the client. You can choose between using one of the trusted certificate authorities (VeriSign, Thawte, GlobalSign) or deploy a root of trust on your clients. The DB client validates the certificate the same way all SSL certificates are validated, by verifying the Subject against the name used by the client to connect.
Given that a normal DB deployment you know what your clients are, then it makes a lot of sense to pre-deploy the certificate used on the client and save yourself the cost of a true SSL system trusted authority signed cert.
If your DB clients are open ended and can add themselves at will, then it doesn't make sense to have them connect to the DB directly. Point is that there must be a deployment step (a Setup) that adds the new client to be trusted on the back end, and this step can also deploy your own root certificate as a new trusted root on the client, or, if the client is paranoid about adding an entire root, just the certificate used by the server as a trusted cert.