Cool Solutions

How to receive an alert when the server certificate is about to expire



By:

January 4, 2012 12:13 pm

Reads:11,377

Comments:2

Score:5

1. Introduction

Don’t you hate it when you get in to work one morning to find your OES/eDirectory services that worked the night before don’t work anymore. When you find that the problem is due to server certificate expiration, don’t you wish that there is some way to inform you before the certificate expires so that you can fix it beforehand. This document explains how this can be done.

2. Understanding the solution

The solution requires you to download a bash script, which means that you can only run this script on an OES server or SLES with eDirectory. The script retrieves all server certificates expiration via LDAP and checks against the current month and year. If the certificates expire within the same month or has already expired, the administrators will be notified via email. If the certificate is going to expire on the same day that the script is run, a special warning will be sent to inform the administrators that they should repair the certificates immediately.

This script should be configured to run on the 1st day of the month at 12:00am. The worst case scenario is that the server certificate has expired on the 1st day of the month before the start of the work day (e.g. at 1am). In this case, the administrators should have already received an email at 12am and repairing the certificate would be the first task of the day.

3. Implementing the solution

3.1. Download the ‘check_certexpire.sh’ script to your OES/eDirectory server (e.g. /usr/local/bin) and make changes to the following variables accordingly.

Variables Description
DOMAIN=novell.com This is your company’s domain name.
Make sure it is a valid one because an
email will be sent to your administrator
using this domain
ADMIN=”admin1@novell.com
admin2@novell.com
admin3@novell.com”
These are the emails of your administrators who will receive the email alerts. Use a space to separate the emails.
LDAPHOST=LDAPHOST.novell.com This is the domain name or IP address of eDirectory server or OES contains a replica of all servers’ OU. Pointing to your Master replica server is a safe bet.Note: This server should allow LDAP search via port 389. To allow LDAP via port 389, open iManager -> LDAP -> LDAP options -> LDAP Group.SERVERNAME -> Uncheck ‘Require TLS for Simple Binds with Password’

If port 389 is not allowed, change the script to use 636 accordingly (look for the ldapsearch command within the script).

Organization=’o=novell’ This is the Organization name configured on the eDirectory Tree. If your servers are located across multiple organization, then use the tree name instead e.g. Organization=’T=novell-tree’

 

3.2. Configure crontab to run this script on the 1st of every month at 12am.
Modify the /etc/crontab accordingly ->

0 0 1 * * root /usr/local/bin/check_certexpire.sh 2>/dev/null

3.3. Configure postfix to enable sending of email.

  • Ensure postfix service is started by typing the following command. The status should show that the service is running ->
/etc/init.d/postfix status
  • Ensure postfix service is started at run time by typing the following command.
chkconfig postfix on
  • Edit the /etc/postfix/main.cf file and ensure that the following line is included into this file
transport_maps = hash:/etc/postfix/transport
  • Find out the IP address (or DNS address) of your SMTP server (e.g. 10.1.1.1) Edit the /etc/postfix/transport file and ensure that the following line is included into this file. Change the IP address below accordingly
* smtp:10.1.1.1
  • Type the following command. Verify that this command updates the /etc/postfix/transport.db file
/sbin/postmap /etc/postfix/transport
  • Finally, try sending an email to yourself by typing the following command on the server. Change yourcompany.com to your company’s domain and youremail to your actual email. Leave $HOST as it is.
echo “this is a test email” | mail -r $HOST@yourcompany.com -s “This is a test subject” youremail@yourcompany.com

4. Testing the solution

You can test this solution by creating 2 certificates that will expire today and expire at the end of the month. Run the script manually and see whether you will receive emails alerts.

To create custom server certificates, do the following:

  • Open iManager -> Novell Certificate Server -> Create Server Certificate
  • Step 1 of 6: Choose the server that you want to create the certificate on. Choose ‘Custom’ as the creation method.
  • Step 2 of 6: Choose Organizational certificate authority
  • Step 3 of 6: Leave everything as default
  • Step 4 of 6: Under Validity period, choose ‘Specify dates’. Select the Expiration date as either today or end of the month.
  • Step 5 of 6: Choose Your organization’s certificate
  • Step 6 of 6: Click Finish.
Note: This solution was tested successfully on an OESSP3 server.

Special thanks to Aska Hsu from China Engineering Consulting Inc. for bringing up this request and testing this solution.

1 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 5 (1 votes, average: 5.00 out of 5)
You need to be a registered member to rate this post.
Loading ... Loading ...

Tags: , ,
Categories: Open Enterprise Server, Technical

Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

2 Comments

  1. By:gmarsh

    This is useful, but my normal practice is, when installing a new server, simply delete ALL the server certs and re-create ONLY the SSL CertificateIP / SSL CertificateDNS certs. When creating, use the Custom setting and create for max length, and edit the Subject Name to match the setting of the old cert.

    After that is done, issue namconfig -k to export the cert to local file system for LUM usage.

    As far as I know, the “…AG…” certs are not used by any component and so do not need to be re-created.

    This way, the certs will last until the CA expires which could be as much as 10 years later, rather than the 2-year default. On the other hand, if the CA will expire within a few years, it is also worth considering first deleting the CA and re-creating it; that can also be done in a Custom way which gets you to about 2036, or a default way which gets you another 10 years.

    If the cert re-creation for max length is done from the outset for every server, it reduces both planned and unplanned downtime.

  2. By:hkprit

    Hi, I am having a small issue trying to set this up on my server. It is running Sles 10 OES2 SP2.

    The second last step in part three, /sbin/postmap /etc/postfix/transfer, is not working for me. When I enter it, I receive an error. “/sbin/postmap: No such file or Directory”. I have checked the file structure and postmap is not present in /sbin. I was however able to find a /usr/sbin/postmap. Would I be able to use that one?

Comment

RSS