I have a web service that is currently being used by a variety of old .Net and Java clients using TLS1.0/SSl3 protocols using a SHA1 certificate.
If I were to change the certificate to be SHA2 would these clients still work ?
I am changing no other configurations on the server (i.e. not disabling TLS1 /SS3).
I will overtime when I can get the clients to upgrade to use TLS1.2.
.NET supports SHA2 since 1.1 (see What's the state of support for SHA-2 in various platforms?)
Java supports SHA2 since 1.4.2. (see https://www.entrust.com/should-you-use-sha-2/)
If you have access to these clients, and if they can connect to a different URL that uses a SHA2 certificate, you should be good. Give the users/ maintainers of these clients a date when you will be migrating your service to use a SHA2 certificate so that they can test it themselves.
Related
I have a product I would like to sell. This product is broken into two physical devices and follows the client server architecture. One device is the server and the other is the client. I am looking to use TLS to secure connection between the server and client.
I would like to setup a server side TLS. I have done research on how to accomplish this with openssl. My strategy at the moment is as follows
create a CA cert
create a Server cert
sign the server cert with the CA
Here's where I struggle to find a solution. I need to support a solution where the two devices do not have access to the internet.
how do I share my CA with clients to complete TLS handshake? To my understanding TLS uses third party to authenticate the cert so you would need internet access if i signed my certs with a CA company
if I share CA with cleint device at production. This works for initial installs but what about once CA cert expires and I need to renew it. Do I just use an API call to get CA from the server. do I have to physically add to the machine every time. Is there any best practices.
lastly is it bad practice to regenerate the CA cert say every 90 days from a script running on the device running the server.
If you only have two devices, and control both, using some kind of shared secret (PSK) between the two devices is likely a lot more convenient and safer that half assing an ersatz PKI. Just make sure it's a different, random, PSK per device pair, and that the owner can actually change them. This is doable with TLS using a PSK suite (see RFC 5489 for TLS 1.2, RFC 7905 for TLS 1.3), but something like IPsec or Wireguard is also perfectly doable.
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.
I'm a novice in regards to Transport Layer Security stuff, to bear with me...
I have some https web apps that I test locally using self-signed certs created with selfssl.exe. The company recently pushed new rules to everyone's machines that prevent the browsers from loading https sites that use anything other than TLS 1.2. However, my browsers give me certificate errors when I load my locally-hosted test stuff if TLS 1.0 is not enabled. Is it possible to generate self-signed certs that will work with my browsers if only TLS 1.2 is enabled?
I'm using Windows 7 64 bit with IIS 7.5, and I test with a variety of browsers (IE 11, Firefox 46, and Chrome 50).
No, it is not possible
SSL/TLS in all versions works with x509 digital certificates. The difference between TLS versions is the protocol rules, not the certificate.
The browser warns usually when the used protocol is old(consideres less secure) or the certificate is not trusted
Eventually figured this out. The answer is kinda dumb...
On Windows 7 / Windows Server 2008 R2, the TLS 1.2 protocol is installed, but disabled by default. When Big Brother pushed everybody to TLS 1.2, they did it with SCHANNEL registry entries, but they did not create the "DisabledByDefault" entry set to "0" so it blew up the security of all the Windows 7 users on the domain.
So, if you're going to use registry hacks to push users over to TLS 1.2, be sure to follow the instructions from Microsoft and remember to create a "DisabledByDefault" entry in the TLS 1.2 SCHANNEL key. :-)
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786418(v=ws.11)
I am using Https and Tcp over SSL in java application with keystores and truststores. I use selfsigned certificates generated by java keytool. I am came to know about HeartBleed vulnerability with openSSL, do I need to change any implementation from java side or I am on safe side. can anyone please give details.
Java does not use OpenSSL, although some Java applications like Tomcat can. As you're using keystores and truststores, you must be using JSSE rather than OpenSSL.
I have academical project to build communicator with Public Key Infrastructure. For communication between server and clients I'll use SSL/TLS and I need for them certificates. I have to build Certificate Authority with CRL and I can do this with openSSL but this tool is only good for manual administrative not for making certificates automatically in remote CA.
To be clear: Clients must register and login to communicator using certificates but it should be made invisible for them. I've tried running openSSL as process in Java but it's not working properly - my previous problem.
Have you any good advice for making simple PKI?
You can use and extend EJBCA. It takes some getting used to but it has support for some HSM's, and it should not be hard to create a small PKI with it. Open source.
A replacement for simple operations of OpenSSL, would be Bouncy castle. To have better CA support you should also use the EJBCA.
To create certificates automatically in the client (I assume you use a client web browser) is a bit trickier. Some browser can generate private client keys and then get them signed by the CA server.
Generating client side certificates in browser and signing on server
In that case, I would also use the EJBCA to make it manageable.