My company uses a code signing certificate purchased from GoDaddy. I use it to sign JAR files containing client UI applications. Each year it expires and wreaks havoc among the Java Web Start users.
I can either recompile the software and generate new JARs, or I can 're-sign' the JARs with the new certificate. There is really no nice way (that I know of) to re-sign a JAR (you must expand it, remove old certificate files, re-compress, re-sign).
The software itself does not change. My question is:
If I originally compiled and signed the software with a legitimate certificate and, if the software does not change, why must I re-sign when the certificate expires? If the software was validated at one time and does not change then why should its validity expire?
I would think the JAR would be more secure if it wasn't messed with periodically.
Related
How the SSL/TLS CA certificate will update automatically in client device if it renewed from website maintainer.
Actually Rooot CA certificate expiry for 1 or 2 years, after that server maintainer should go to certificate Authority renewal for further validity, so in this condition how the client device update new renewed certificate?
I could get some answers from websites like if the certificate expire then we will get some warning message and data communication also plain text , so that it is vulnerable for man in the middle attack.
Thanks!
There are many unclear aspects in your question - for example, what is this "device" that requires (or don't require) firmware upgrade - so I'll answer in general.
Yep, the way simplest to describe is just the firmware upgrade. If it is expected that a device needs checking against a well-known root certificate set, this is to be implemented by upgrading this set as well. It depends on OS and ditribution how it is implemented; e.g. in non-embedded Linux distributions it is present as a package named "ca-certificates" or similar. The package provides a directory of certificates in PEM form, or a single file of concatenated certificates, or both. The package is upgraded independently of other components, except possible relation on data form.
It is used in some cases that a certificate (as a combination of its subject, public key and attributes) is provided in two versions: self-signed - for newly updates users, and signed by a previous certificate - for users with old certificate database. Depending on client software, it may issue expiration warning, if old root is expired, or may not.
Some root certificates are provided with long lifetime (20-30 years) but used just to sign second level certificate which lives a few years; the latter, in turn, is used for end-user certificates (as web server). In such case, you don't need to react at all.
I'm working on an embedded system that performs requests to a REST API with HTTPS. In my understanding, the SSL certificate of the server is verified using a bundle of trusted certificates stored locally. In my case they are in a Debian-based package called ca-certificates. This package is from 2019 so I wonder if I have to worry about this package being obsolete one day. If yes, when?
This package is from 2019 so I wonder if I have to worry about this package being obsolete one day. If yes, when?
The CA certificates in the package have a limited life time. For details look at the expiration times in the specific certificates. Also new publicly trusted CA might be added or less trusted ones removed.
In general it might not be a good idea in the first place to simply trust all public CA in your embedded system in the first place. If there is a fixed endpoint for your device than certificates and CA used there should be trusted instead of the whole world. When doing this the problem gets also smaller, i.e. you only have to worry about the specific CA used and not arbitrary changes to the trusted CA store.
I have bought a domain and certificate from Azure. The certificate is given by Go Daddy as azure partner and it is signed with the intermediate certificate from Go daddy hence it always needs chaining of certificates till Root CA.
Our website is used as a REST interface for our customers and hence clients use Java SDK or plain scripts. In our case precisely with zulu jdk image(11u5-zulu-alpine) from microsoft and even I tried with ubuntu 16.04 LTS and get the same error.
if we try to even curl to our site with proper certificates we get error as below and its because of the intermediate CA is missing!
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
With java SDK we get as javax.net.ssl.SSLHandshakeException
I have 3 questions.
Do we need to bundle the intermediate and root certificate with our domain certificate and deploy it.( the certificate is in pfx format)
Is it a good practice to tell our clients to install the bundle certificates ( root and intermediate) in order to get this working.
Does GoDaddy needs to update the bundle certificate in the packing repositories of Ubuntu ,alpine Or is my understanding wrong
And lastly I have a fair idea of how certificates work w.r.t client and server but with the intermediate CA in picture I am unable to understand exactly where the intermediate CA should be put in. I read few posts on the SO but its still unclear. Please bear with me and if some one can explain me the approach how it works in general and what could be the good practice.
Do we need to bundle the intermediate and root certificate with our domain certificate and deploy it.( the certificate is in pfx format)
You should definitely configure the server to send all required intermediate certs; this is required by the TLS standards. (Although if you don't, clients have the option to try to obtain them by other means, like a cache or repository or AIA, and sometimes they do.) Whether the server sends the root is optional; the standards actually state this in reverse, by saying the server MAY omit the root, where the all-caps 'MAY' invokes the meaning defined in RFC 2119. E.g. for TLS1.2 in RFC5246 7.4.2:
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
How you do this depends on what web-server software you are using, which you didn't identify. Although from the fact you specify a Java version, I can speculate it might be Tomcat, or something based on Tomcat like Jboss/Wildfly. Even then, Tomcat's SSL/TLS configuration varies substantially depending on the version and which type of connector 'stack' you use (the pure-Java JSSE, or Tomcat Native, aka APR Apache Portable Runtime, which is actually OpenSSL). However, a 'pfx' (PKCS12) file can definitely contain both a privatekey and the matching (EE) certificate PLUS the chain cert(s) it needs, and is a convenient way to deal with the whole kaboodle at once.
For a cert obtained directly from GoDaddy, they provide instructions linked from https://www.godaddy.com/help/install-ssl-certificates-16623 for many common servers. I don't know if for Azure they use any different chaining that would alter these instructions.
If your server is publicly accessible, at port 443, https://www.ssllabs.com/ssltest will check if it is correctly handling the chain certs, as well as many other things. There are other tools as well but I am not familiar with them; for non-public servers I usually just look manually.
Is it a good practice to tell our clients to install the bundle certificates ( root and intermediate) in order to get this working.
Clients should not install intermediate cert(s) because as above the server should send them. The GoDaddy roots have been accepted in most official truststores for several years now, so most clients using default settings should not need to add them. However, some might; in particular Ubuntu 16.04 might be old enough that it doesn't have GoDaddy preinstalled. And any client(s) that wishes to use a customized truststore, and/or a pin, must ensure that it is set to include/allow your cert's trust chain.
Does GoDaddy needs to update the bundle certificate in the packing repositories of Ubuntu ,alpine Or is my understanding wrong
GoDaddy has supplied its roots to (AFAIK all) the major truststore programs, as above. IINM Ubuntu uses the Mozilla/NSS list, which definitely includes GoDaddy today, but as above I can't be sure about 16.04. I don't know for alpine. CAs do not request truststore programs to include intermediates (although a program or user may be able to add selected intermediate(s) as trusted, depending on the software used).
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.