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.
Related
I am working on an embedded device (Arduino) that connects securely to specific domains. To achieve this, certificates (domains), e.g. arduino.cc:443, are uploaded to the device via an updater tool (WiFiNINA certificates updater in Arduino IDE).
I'm wondering whether these certificates will need to be updated in the future? The plan is to ship the devices to customers, so I'm hoping this will not be necessary.
As long as the server side domain/website/api keeps its certificates updated, I assume it will not be necessary to update certificates on the clients?
Thanks.
All certificates have a limited life time and this is true for client certificates too. Depending on the life time of the certificate and the expected life time of the device this means that the certificate needs to be renewed - assuming that normal certificate validation is done. Of course one might decide to use a different certificate validation on the server, like pinning to a specific public key and ignoring any expiration.
I am new to TLS/SSL so this might be a very basic question, but I've been searching a lot an could not find an answer.
I am trying to implement a TLS/SSL client. This client will run on an embedded unit with Windows OS on it (XPe or WES7). My implementation uses GnuTLS.
How do I get the list of trusted authorities to my unit so my client can verify the server's certificate? Is it supposed to be a file stored on the client side, that the client is responsible for keeping up to date? Or can my client somehow get this list from the internet each time it is needed and not maintain it locally?
The Certificating Authority (CA) master certificates are stored client side and the client is responsible for keeping them up to date. Keeping them up to date isn't as hard as it sounds, as CA certificates aren't changed that often - most are valid for 5-10 years at least.
Client side storage is necessary because any given internet site your application uses might be compromised.
To get a list, you might start by looking at the CA certificates distributed with a browser or at the cacerts file distributed with Java. Before releasing your code, you'll probably want to check that the certs you use are genuine by checking them against information provided by the CA.
Go to any Windows machine and run "certman.msc" from command-line. Export each CA certificate (Intermediate Certificates, Trusted Authorities) to file (BER, PEM), then import these certificates into your embedded software. Now you can validate email certificates, the same way Windows does (i.e. using various x.509 related RFCs and CRLs)
I have a web service which is secured through HTTPS. I also have client software which talks to this web service, using libcurl (which may be linked to OpenSSL, or linked to GnuTLS; I don't know which one, it depends on how the user installed libcurl). Because the web service is only ever accessed through the client software and never through the browser, the web service utilizes a self-signed certificate. The client software, in turn, has a copy of this self-signed certificate and explicitly checks the connection against that certificate.
Because of Heartbleed, I want to change the private key and certificate. However I want my users to experience as little service disruption as possible.
For this reason, I cannot change the key/certificate on a fixed date and time. If I do this then all users must upgrade their client software at that exact date and time. Otherwise, the upgraded client software won't work before the server change, while old versions of the client software won't work after the server change.
Ideally, I want to tell my users that I'm going to change the certificate in 1 month, and that they have 1 month time to upgrade the client software. The client software should be compatible with both the old and the new certificate. Then, after 1 month, I can issue another client software update which removes support for the old certificate.
So now we've come to my question: can I append the old certificate and the new certificate into a single .crt file? Will this cause libcurl to accept both certificates? If not, what should I do instead? Does the behavior depend on the SSL library or version?
Tests on OS X seem to indicate that appending both certificates into a single file works, but I don't know whether this is OS X-specific behavior, or whether it works everywhere. My client software has to support a wide range of Unix systems, including Linux (multiple distros) and FreeBSD.
Short answer: You can't.
Long answer:
Yes you can put multiple certificates in a single .crt file, regardless of platforms.
However HTTPS can only serve one certificate, instead of a crt file. So it's not the file that is limiting you, it's the protocol.
You could have a look at SNI https://en.wikipedia.org/wiki/Server_Name_Indication
to be able to serve another certificate based on the SNI information sent by the client at the beginning of the SSL Handshake
Alternatively, you could use a separate TCP port (or IP, or both) that will serve the new certificate.
But you say
The client software, in turn, has a copy of this self-signed certificate and explicitly checks the connection against that certificate.
This then requires you to release a version of your software for your clients to run, to at least have the copy of the new certificate you are going to use.
I guess you should better use a certificate signed by well-known CA, to decouple your server certificate from its validation chain, but that indeed means paying.
Yes a cert file should be able to hold multiple certificates. I would expect this to be broadly supported.
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!
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.