I like to have a working mail setup on all machines as this allows to be notified about cronjobs that failed and also to be able to send other notifications that would otherwise be lost. It is also especially useful for things like git send-email or automatically sending GPG signatures with caff to others.
However, mails cannot just be sent from any device and mail servers on the internet usually reject mails from dial-up IPs or public WiFi networks. To fight spam, techniques like SPF have been developed that restrict the mail servers that are allowed to send mails for the domain name used in the From: field. Therefore the best way is to relay all outgoing mail through the mail server that is responsible for your domains.
While most tools also allow you to configure an external SMTP server, it is on one hand tedious to configure it everywhere and on the other hand also insecure if you have to write the username and password for authentication to many user-readable configuration files on your system. Therefore I am running a local MTA on all the computers I administrate to relay mails to a central mail server.
About a year ago, I wrote an article why I no longer trust StartSSL. Back then, I said I switched to a paid certificate issued by Comodo under the PositiveSSL brand instead. A reader now brought a recent issue with a Comodo certificate erroneously issued for Microsoft’s Windows Live to my attention and asked whether I would still prefer them over StartSSL.
Do you still trust Commodo to be more trustworthy than StartCom just because they asked for money to handle revocations? Think twice – a guy from Finland managed to get a valid certificate from Commodo for “live.fi”, (Microsoft Live in Finland), just because he was able to register “firstname.lastname@example.org” as his e-mail-address:
Recently I found some new bug in ssl-cert-check, my tool for checking the expiry dates of local and remote SSL certificates. The tool has worked fine for me over the years, but I used to have expiry dates that were very close to another, so I never noticed that it did not work for web servers using SNI to serve multiple domains with virtual hosts from the same IP address. I am sorry I did not think of this earlier. I fixed the bug now and in case you have such a setup, I encourage you to get the new release.
I also noticed it becomes cumbersome to maintain the updates with blog posts and downloads here. Therefore, ssl-cert-check is now on Github and I will continue to make releases from there.
In my previous post, I presented a mechanism to check the remaining lifetime of an SSL certificate using the PEM certificate file locally on disk. However, in the case with Azure recently, customers were dependent on the actions by Microsoft and had no access to the actual file. Thus, there might be a need to check remote certificates of services you use, e.g. your off-site backup provider. As you want to ensure you can always use this service, why not check this for expiring certificates once in a while? Maybe it’s your notification to the sysadmins who saves yourself and all other customers from being locked out.
Here is the updated script ssl-cert-check that now not only handles x509 certificate files, but also remote addresses for various forms and protocols. For simplicity, here are the usage instruction from inside this script:
Once again I missed the expiry date of one of the SSL certificates on my server. Therefore I am now using a cronjob to warn me early enough that a certificate is about to expire.
This is the script /usr/local/bin/ssl-cert-check which checks the expiry date of the certificate files passed as arguments:
openssl x509 -checkend $((86400*$DAYS))-in"$file">/dev/null
if[$?!= 0]; thenecho"==> Certificate $file is about to expire soon:"
openssl x509 -enddate-in"$file"-nooutfidone
And the corresponding cronjob entry checking SSL certificates once a day: