Cron warns me ca-certificates.crt is about to expire.
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Cron warns me ca-certificates.crt is about to expire.
The cron script certwatch has emailed me to warn ca-certificates.crt is about to expire, "it might be a good idea to obtain/create new one". I want to ensure two things: I correctly update ca-certificates.crt; I don't inadvertently re-authorise an expired certificate.
I gather from googling that ca-certificates.crt is a bundle of all the linked certs in various locations. So I guess it is not so much that ca-certificates.crt is about to expire, but rather that one of the contained certificates is about to expire.
for i in /etc/ssl/certs/* ; do
openssl x509 -noout -dates -in $i
shows that some of the certs do have expired notAfter dates, some as old as 2006.
Do I just delete those old certs? Or, how do I update them?
After that, I guess I run "update-ca-certificates" and I am good to go?
Thanks for any help,
Click here to see the post LQ members have rated as the most helpful post in this thread.
No, I don't think that this is the solution he asked for. We are not talking about a selc-signet certificate for Apache or mail, my self-signed-certificates are definitely not out of date and I received the same message by certwatch on my mail server this morning.
I guess does not only those two installations.
Edit: All my Slackware installations have sent me this message.
Distribution: openSuSE, Fedora, CentOS, Debian,, and others
j-ray is correct.
Depending on how the SSL Certs were generated, 99.999999% of the time if the Expire date is set to anything that old, then it is most likely a Self-Signed Cert. The most common that has a date that old is cPanel, iRedOS, and if I recall correctly unless you specify a specific time when generating a Self-Signed Cert the date is well in the past. Of course this does not mean that the Cert is "bad" or that the encryption won't work, but it does mean that it's time to get a new SSL Certificate.
Here's what I think is going on. The /etc/ssl/certs/ca-certificates.crt file generated by the ca-certificates-20090814 package used by OpenSSL expires in 7 days or less. You can check the file using the following command:
That's correct. More specifically, it's the brasil.gov.br.crt certificate which expires on 30 November. It appears that certwatch is checking the expiry date on the first certificate in the ca-certificates.crt bundle. If you look in /etc/ca-certificates.conf, you'll see that brasil.gov.br.crt is the first line.
If you like, you can comment out any expired certificates in this file, then update your /etc/ssl/certs directory with:
Or you can do nothing and wait for an updated ca-certificates package with the expired certificates removed. The slackware ca-certificates package is based on the Debian one, and Debian testing has a newer version (20111025 as opposed to 20090814). Presumably this will make its way into Slackware some time after it hits Debian stable.
Either way it doesn't really matter because, as the email says, it'll only be sent once unless you remove /var/run/certwatch-mailwarning-sent-ca-certificates.crt.
I see the same email message with both 13.37 and Current.
Curious, in 13.37 I ran the script manually and I received these stdout messages:
unable to load certificate
2570:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1315:
2570:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:379:Type=X509
date: invalid date `+%s'
The date error occurs because 1) the script has no error trap against an empty variable $DATE_CERT_EXPIRES and 2) the variable is empty.
The stdout messages are triggered by the following:
openssl x509 -in "/etc/ssl/certs/ca-certificates.crt" -inform DER
A litte investigating eventually revealed an updated script is available in Current in the n/openssl package.
Yet I remained unsatisfied.
Running /usr/sbin/update-ca-certificates --verbose has no effect. The only thing the command does is update /etc/ssl/certs/ca-certificates.crt and not update actual certificates. The script provides no information about which certificates are at fault.
Some changes to the script results in improved information.
* I updated my script from Current.
* I added a simple error trap for the date error.
* I revised the messages. The current message implies the problem is with /etc/ssl/certs/ca-certificates.crt, but the problem is outdated certificates. The new messages clarifies the problem.
* I added some text in the email message how to view a list of the problematic certificates (run the script in a terminal with the 'stdout' parameter).
* When running the script in a terminal to stdout, I borrowed some script snippets from Eric to show a list of problematic certificates.
I think you better don't delete them unless you know what you are doing. Applications relying on encryption can still use them and maybe will spit out some warnings but maybe some will crash without them? I think it's better to tell certwatch not to watch these if the server is not providing real users with real services.
your script displayed that there is 16 expired certificates in my Slackware 13.37. The mentioned above brasil.gov.br.pem expired 2 days ago. The oldest GTE_CyberTrust_Root_CA.pem expired 2108 days ago.
Thank you for the script. It'll be good to see it in the future Slackware release integrated with the mechanism that sends e-mail to root.