LinuxQuestions.org - Cron warns me ca-certificates.crt is about to expire.

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Cron warns me ca-certificates.crt is about to expire. (https://www.linuxquestions.org/questions/slackware-14/cron-warns-me-ca-certificates-crt-is-about-to-expire-915251/)

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.

Code:

for i in /etc/ssl/certs/* ; do

  echo $i

  openssl x509 -noout -dates -in $i

done

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,
Nick
OpenSSL newbie
Slack 13.37

If it is a production server, for real world applications, you have to buy new certificates and install them. For development purposes you can create them yourself:
http://slacksite.com/apache/certificate.php

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.

j-ray is correct.:Pengy:

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.

I created one of the certificate just a couple of weeks ago and set the expire date three years in the future, definitely. I just ckecked that to make sure.

It seems odd to me, that all certificates on several slackware machines at different users expire at the same time....

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:

Code:

root@slacker:/# /usr/bin/openssl x509 -noout -in /etc/ssl/certs/ca-certificates.crt -dates    

notBefore=Nov 30 12:58:00 2001 GMT                                                                      

notAfter=Nov 30 23:59:00 2011 GMT                                                                        

root@slacker:/#

The certs contained in the ca-certificates.crt can be found in the /etc/ca-certificates.conf file.

I plan to leave the /var/run/certwatch-mailwarning-sent-ca-certificates.crt file in place until the ca-certificates file gets updated.

YMMV

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:

update-ca-certificates --fresh

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.

20111025 still got the brasil.gov.br.crt.

tried to do an updated package (sources).

EDIT: corrected just a little to remove it only from /etc/ssl/certs/ca-certificates.crt (certificate is still there).

EDIT2: but I think maybe certwatch shouldn't check that file at all
http://pastebin.com/raw.php?i=V5m41fLZ
and so brasil.gov.br.crt can stay there.

I agree, the purpose of certwatch should be to remind you when your own certificates are about to expire, not to complain about expiring CA certificates.

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:

Code:

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.

Only thing remaining is get updated certificates. :)

Let me know how the revised script works for you.

So, still no solution for the problem. And my servers is complained of this problem. I will get back here daily to check if someone is solve it.
Regards!

as I said before, in my opinion there's no real problem: certwatch shouldn't check that file (the little patch I proposed above).

Quote:

Originally Posted by ponce (Post 4535020)

as I said before, in my opinion there's no real problem: certwatch shouldn't check that file (the little patch I proposed above).

Thanks. With the out-of-date certificates, are they safe to leave or should they be deleted? I hope that openssl or any application that uses it will refuse to use them.

Perhaps I should just go ahead and delete all the expired ones.

Nick

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.

Woodsman,

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.