I have a successful connection with an ESP32 and aws. Now, I have read, that the certs have an expiration date. So is it possible to extend the date or is it necessary to change the certs. If it is necessary is there a way to change it automatic?
If you use the certificates that AWS IoT core generates for you, then they will expire at midnight UTC on December 31, 2049. The same site states:
Devices and clients must also support rotation and replacement of certificates to help ensure smooth operation as certificates expire.
So if you expect your ESP32 to live and work for almost 28 years, then you have to make sure you can rotate/replace the certificates. You could write some software that enables you to change the certificates through AWS IoT jobs. Generate a new certificate before the current certificate expires. Put the new certificate on S3 and send a pre-signed URL to your device through an AWS IoT job that will trigger a script (you have to write this script) to download the new certificate and replace the current one.
Keep in mind that it's likely you won't only have to replace the device certificate sooner or later but also the CA, in case it expires or AWS decides to change the root CA. Which happened before.
Alternatively, you can create your own CA with its own expiration date and use this for your device. In this case you could set your expiration date to 100 years in the future, which would be fine for your private setup but not for production use with multiple devices distributed across the country or even globe.
If what you're doing is unimportant (like a hobby), you could modify the code to just skip the step of authenticating the connection destination via a CA. That way it would work forever, or until someone bothered to attack you as a "man in the middle".
For AWS IoT things, I think you can make/upload your own certificates to AWS IoT Core which could last ~ 80 years, I estimate.
I have not tried these methods yet.
Related
Is there is any way to get around the SSL certificates in the wallets expiring, having looked at the expiry date that is in the wallet.zip README file as well as the orapki utility.
If one cannot get around SSL certificates expiring what is the recommended way of managing SSL certificates and their expiry?
Autonomous Database takes security seriously, so there's no way to get around an encrypted, secure connection and you will need to download new wallets before their expiry date. You can have multiple wallets with different expirations concurrently, so there is no service interruption.
Depending on your application, you may also consider enabling mTLS to go walletless, which we released recently! Read Todd Sharp's post about this as well as the ADB documentation for more detail.
Ref: I am a product manager on the Oracle Autonomous Database :)
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 trying to lunch new servers automatically when needed but I am having some difficulty getting the certificate before making the server live. What I want to do is run a setup script which gets all the packages, websites and certificates ready and after that add the server to production. However, Letsencrypt wants me to verify that the server requesting the certificate is actually the website which replies to requests. How can I get the Letsencrypt certificate before adding the server to production? I don't want requests to the real website to be routed to the new server until it is fully setup and has the certificates.
One solution I thought of is to save the certificates on an AWS S3 bucket and synchronize them whenever a renewal is needed. Then when I setup a new server I just get the latest certificate from my AWS S3 bucket and I don't have to worry about getting the certificate from the CA until after the server is added to production.But this solution doesn't seem "clean" and would require me to have an S3 bucket just for my Letsencrypt certificate which also adds another weakness where a certificate could be stolen from.
Is there a more simple solution which I haven't thought of yet?
In a load-balanced (LB) scenario, you should consider having exactly one entity responsible for performing LE certificate acquisition. Things get complicated with multiple entities doing this asynchronously - you'd need to be able to guarantee that the ACME challenges get routed to the relevant server(s), and your LB doesn't have that information (without additional complexity).
So I'd suggest either:
Terminating HTTPS at your load-balancer. Then none of your servers need to care about HTTPS or certificates.
Having one "special" server that's responsible for interacting with LE, and then distributing the cert to the other servers. The details of how you do that is implementation-dependent, because it depends on how you're managing server/service configuration.
I'm using SSL certificates in a client-server application; both the client and the server are using 2 certificates that will expire soon. Normally, you'd just replace the certificates with new ones, but this cannot happen at once because of the huge numbers of clients.
So, if only the servers and a part of the clients are updated, the rest of the clients won't be able to authenticate anymore.
A quick fix is to replace the binaries with a version which simply disregards expiry date of the certificates; the update of the clients can be done sequentially, as long as it will finish before the certificates expire.
Long term solutions I thought about:
use Puppet to push new certificates on clients
unfortunately, not viable because not all clients are/will be managed via Puppet
use a second set of certificates
if first set has expired, use the second one
in this manner, server will have new certificates, a part of clients will have new certificates and the rest of the clients will have old certificates, but everything works
client requests a new certificate from the server, if the current one has expired.
Are there any other solutions?
I assume you use the SSL certificates for an online SSL connection, like HTTPS, or SFTP.
The big question is: Do you still trust and want to use your server-side key! If so you can just re-issue the server certificate with a new expiration date still using the old key and thus extending the lifetime. The question is, if you still trust the old key or if it should be replaced. Old clients may still connect to you at that point.. You are still using the same public / private key pair, just made a new 'lifetime version' of the certificate for it. (That is what most public servers do..)
Using two sets of active SSL certificates for different keys on the server side is not really viable and only possible if you have good control over the handshake process on the client side and your server application supports it. The issue is that during an SSL negotiation, the server has to send its certificate first and the only indication it might get from the client is a ServerName extension during the ClientHello. (Assuming the client actually sends one). Otherwise the server is 'at a loss' on what the other side will or will not support. (There are some other extensions that might help for in indicating supported CA certificates, but your clients should support those).
The first is the most practical for the clients that do support it. Just renew their certificates (and perhaps keys) and push them. And you are done with those.
For the others, updating the client software and making sure they generate a new key and request a new certificate from the server when they need it (or in advance) might be the best solution.
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.