Monitor SSL Certificate Expiration/Replace Expired SSL Certificates Automatically

Problem : I have websphere systems which are roll forwarded in future and then rolled back to current date. Certain times I get SSL errors in my log despite setting option to replace expired certificates at deployment manager.

The certificate expiration monitor task runs under the deployment manager process.

The certificate expiration monitor administrative task cycles through all the keystores that are configured in the security.xml file and reports on any certificates that expire within a specified threshold, which is typically within 30 days.

The default self-signed certificate on each node expires 365 days after creation. You can modify the certificate validity period by changing the default value for the com.ibm.ssl.defaultCertReqDays=365 property in the ssl.client.props global property area for clients. You can also specify this property as a security custom property on the administrative console. Click Security > Secure administration, applications, and infrastructure > Custom properties.

The expiration monitor automatically replaces only self-signed certificates that meet the expiration threshold criteria.

<wsSchedules xmi:id=”WSSchedule_2″ name=”ExpirationMonitorSchedule” frequency=”28″ dayOfWeek=”1″ hour=”21″ minute=”30″ nextStartDate=”1312144223207″/>
<wsNotifications xmi:id=”WSNotification_1″ name=”MessageLog” logToSystemOut=”true” emailList=””/>
<wsCertificateExpirationMonitor xmi:id=”WSCertificateExpirationMonitor_1″ name=”Certificate Expiration Monitor” autoReplace=”true” daysBeforeNotification=”60″ isEnabled=”true” wsNotification=”WSNotification_1″ wsSchedule=”WSSchedule_2″/>

To replace all of the signers from the old certificate with the signer that belongs to the new certificate in all the keystores in the configuration for that cell, set the autoReplace attribute to true.

When the deleteOld attribute is true, the old personal certificate and old signers also are deleted from the keystores.

The isEnabled attribute determines whether the expiration monitor task runs based upon the nextStartDate attribute that is derived from the schedule. The nextStartDate attribute is derived from the schedule in milliseconds since 1970, and is identical to the System.currentTimeMillis(). If the nextStartDate has already passed when an expiration monitor process begins, and the expiration monitor is enabled, the task is started, but a new nextStartDate value is established based on the schedule.

<wsNotifications xmi:id=”WSNotification_1″ name=”MessageLog” logToSystemOut=”true” emailList=””/>

For expiration monitor notifications, you can select message log, e-mail using SMTP server, or both methods of notification. When you configure the e-mail option, use the format user@domain@smtpserver.

To specify multiple e-mail addresses using scripting, you must add a pipe (|) character between entries. When you specify the logToSystemOut attribute, the expiration monitor results are sent to the message log for the environment, which is typically the SystemOut.log file.