Certificate expiration monitoring
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 property...
com.ibm.ssl.defaultCertReqDays=365...in the ssl.client.props global property area for clients. You can also specify this property as a security custom property on the console. Click...
Security | Secure administration, applications, and infrastructure | Custom propertiesThe certificate expiration monitor task runs under the deployment manager process.
You can configure this monitor task to run according to a particular schedule. The schedule produces the next start date that persists in the configuration and, when the date is reached, WAS starts the monitor to check all of the keystores for certificates that meet the expiration threshold. You can start the task manually to run at any time.
The following security.xml configuration object specifies when the monitor task starts, determines the certificate expiration threshold, and indicates whether you are notified in an e-mail using SMTP or in a message log.
<wsCertificateExpirationMonitor xmi:id="WSCertificateExpirationMonitor_1" name="Certificate Expiration Monitor" daysBeforeNotification="30" isEnabled="true" autoReplace="true" deleteOld="true" wsNotification="WSNotification_1" wsSchedule="WSSchedule_2" nextStartDate="1134358204849"/>The expiration monitor automatically replaces only self-signed certificates that meet the expiration threshold criteria. 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.
The following sample code shows the frequency attribute as the number of days between each run.
<wsSchedules xmi:id="WSSchedule_2" name="ExpirationMonitorSchedule" frequency="30" dayOfWeek="1" hour="21" minute="30"/>The dayOfWeek attribute adjusts the schedule to run on a specified day of the week, which is always the same day regardless of whether the frequency is set to 30 or 31 days. Based on 24-hour clock, the hour and minute attributes determine when the expiration monitor is started on the specified day.
The following sample code shows the notification configuration, which notifies you after the expiration monitor runs.
<>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. If you do not specify an SMTP server, WAS defaults to the same domain as the e-mail address.
For example, if you configure joeuser@ibm.com, WAS attempts to call smtp-server.ibm.com. To specify multiple e-mail addresses using scripting, 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.
Related concepts
Default self-signed certificate configuration