LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
LinkBack Search this Thread
Old 11-23-2011, 11:55 PM   #1
padeen
Member
 
Registered: Sep 2009
Location: Perth, W.A.
Distribution: Slackware 14, Debian 7, FreeBSD, OpenBSD
Posts: 158

Rep: Reputation: 32
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
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 11-24-2011, 01:48 AM   #2
j-ray
Senior Member
 
Registered: Jan 2002
Location: germany
Distribution: ubuntu
Posts: 1,389

Rep: Reputation: 97
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
 
Old 11-24-2011, 02:02 AM   #3
nebulein
LQ Newbie
 
Registered: Nov 2009
Location: Germany
Distribution: Slackware
Posts: 6

Rep: Reputation: 0
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.

Last edited by nebulein; 11-24-2011 at 02:18 AM.
 
Old 11-24-2011, 03:53 AM   #4
War3zWad|0
Member
 
Registered: Sep 2011
Location: Houston, TX
Distribution: openSuSE, Fedora, CentOS, Debian,, and others
Posts: 84

Rep: Reputation: Disabled
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.
 
Old 11-24-2011, 04:16 AM   #5
nebulein
LQ Newbie
 
Registered: Nov 2009
Location: Germany
Distribution: Slackware
Posts: 6

Rep: Reputation: 0
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....
 
Old 11-24-2011, 09:37 AM   #6
Chuck56
Member
 
Registered: Dec 2006
Location: Colorado
Distribution: Slackware
Posts: 418

Rep: Reputation: 58
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
 
Old 11-24-2011, 09:59 AM   #7
mgrocock
LQ Newbie
 
Registered: Nov 2011
Distribution: Slackware
Posts: 2

Rep: Reputation: Disabled
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.
 
Old 11-24-2011, 11:32 AM   #8
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,314

Rep: Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816
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.

Last edited by ponce; 11-24-2011 at 02:03 PM. Reason: fixed package (just an update)
 
Old 11-24-2011, 01:39 PM   #9
mgrocock
LQ Newbie
 
Registered: Nov 2011
Distribution: Slackware
Posts: 2

Rep: Reputation: Disabled
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.
 
Old 11-24-2011, 07:08 PM   #10
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,256

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
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.
Attached Files
File Type: txt certwatch.txt (5.0 KB, 44 views)

Last edited by Woodsman; 11-24-2011 at 07:12 PM.
 
2 members found this post helpful.
Old 11-27-2011, 02:28 AM   #11
RealUseR
LQ Newbie
 
Registered: Jun 2007
Distribution: Slackware Current
Posts: 22

Rep: Reputation: 13
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!
 
Old 11-27-2011, 02:45 AM   #12
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,314

Rep: Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816Reputation: 816
as I said before, in my opinion there's no real problem: certwatch shouldn't check that file (the little patch I proposed above).
 
1 members found this post helpful.
Old 11-27-2011, 05:14 AM   #13
padeen
Member
 
Registered: Sep 2009
Location: Perth, W.A.
Distribution: Slackware 14, Debian 7, FreeBSD, OpenBSD
Posts: 158

Original Poster
Rep: Reputation: 32
Quote:
Originally Posted by ponce View Post
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
 
Old 11-27-2011, 06:23 AM   #14
j-ray
Senior Member
 
Registered: Jan 2002
Location: germany
Distribution: ubuntu
Posts: 1,389

Rep: Reputation: 97
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.
 
Old 12-02-2011, 01:45 PM   #15
w1k0
Senior Member
 
Registered: May 2008
Location: Poland
Distribution: Slackware, Mint
Posts: 1,240

Rep: Reputation: 187Reputation: 187
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Strange Cron directories: /var/spool/cron/cron.GfqqGO Woodsman Slackware 4 05-11-2011 02:37 PM
cron.hourly cron.weekly cron.monthly and 0anacron. Are they necessary? glore2002 Debian 2 09-30-2009 08:57 PM
adding a perl script to cron.daily / cron.d to setup a cron job CrontabNewBIE Linux - Software 6 01-14-2008 08:16 AM
cron not working from crontab nor form /etc/cron/cron.d. What did SuSE change? JZL240I-U Suse/Novell 11 01-04-2007 01:57 AM
Can any one plz explain why/what for cron.d, cron.daily, cron.weekly etc are there. mavinashbabu Linux - Newbie 4 09-21-2006 01:50 PM


All times are GMT -5. The time now is 02:35 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration