Technical Blog Post
Abstract
z/OS: The Mystery of the SSL Certificate Expiry Date
Body
I am Kawsar Kamal from the WebSphere for z/OS defect support team. I came across an interesting scenario recently that makes a good candidate for my first entry into the WebSphere blog.
Background:
Personal certificates are signed by a Certificate Authority (CA). Both the CA and the personal certificates have a time range between which they are valid. In addition, the certificate start time (and date) must be later than or equal to its signer CA start time, and the certificate end (expiry) time must be earlier than or equal to CA end time. If the above two conditions are not met, the certificate is labeled as NOTRUST by RACF. This is a bad state for a certificate to be in as it becomes unusable for all intended purposes (such as SSL Handshakes). Although one can manually override the NOTRUST status to TRUST, there is no guarantee that a certificate in this state will be accepted by code that is processing it. The certificate start and end date-time are reported by RACF as NOTBEFORE and NOTAFTER fields respectively.
Personal certificates are signed by a Certificate Authority (CA). Both the CA and the personal certificates have a time range between which they are valid. In addition, the certificate start time (and date) must be later than or equal to its signer CA start time, and the certificate end (expiry) time must be earlier than or equal to CA end time. If the above two conditions are not met, the certificate is labeled as NOTRUST by RACF. This is a bad state for a certificate to be in as it becomes unusable for all intended purposes (such as SSL Handshakes). Although one can manually override the NOTRUST status to TRUST, there is no guarantee that a certificate in this state will be accepted by code that is processing it. The certificate start and end date-time are reported by RACF as NOTBEFORE and NOTAFTER fields respectively.
Scenario:
Somehow a CA has a NOTAFTER date-time that is one or more hours earlier than the default RACF NOTAFTER date-time of 23:59:59. This causes certificates with NOTAFTER date-time of 23:59:59 to go into NOTRUST status.
Somehow a CA has a NOTAFTER date-time that is one or more hours earlier than the default RACF NOTAFTER date-time of 23:59:59. This causes certificates with NOTAFTER date-time of 23:59:59 to go into NOTRUST status.
RACDCERT CERTAUTH LIST(LABEL('WebSphereCA')) #Displaying the CAStatus: TRUSTStart Date: 2008/06/11 23:00:00End Date: 2030/06/30 22:59:59
RACDCERT LIST (label('DefaultWASCert')) ID(ASCR1) #Displaying the Personal CertificateStatus: NOTRUSTStart Date: 2010/01/12 00:00:00End Date: 2030/06/30 23:59:59
Both the CA (WebSphereCA) and the certificate (DefaultWASCert) were created by WebSphere install jobs. The GENCERT commands in these jobs to create the certificates only supply a NOTAFTER DATE, they do not supply a TIME parameter. Therefore, RACF uses a default TIME of 23:59:59. So how did the CA end up with a time of 22:59:59, when RACF has 23:59:59 hardcoded?
How did it happen?
When generating a personal certificate or a CA, RACF will calculate its default "End date" to 23:59:59 Local time. It will then convert the 23:59:59 Local time to GMT time and store that GMT time in the certificate. Therefore, if the same personal certificate or CA is transferred to a different timezone than it was created in, the same GMT time of 23:59:59 will convert to a different local time (in this case 22:59:59).
When generating a personal certificate or a CA, RACF will calculate its default "End date" to 23:59:59 Local time. It will then convert the 23:59:59 Local time to GMT time and store that GMT time in the certificate. Therefore, if the same personal certificate or CA is transferred to a different timezone than it was created in, the same GMT time of 23:59:59 will convert to a different local time (in this case 22:59:59).
In the above example, the CA was created during the summer months in CEST timezone (Central European Summer Time). CEST = GMT+2h. Therefore, the "End Date" of 23:59:59 CEST was stored as 21:59:59 GMT in the certificate. Then during the winter months, when the certificate is displayed in CET timezone (Central European Time), GMT+1h, RACF converts the "End Date" of 21:59:59 GMT to local 22:59:59 CET.
Therefore, when the certificate is being generated and signed with the CA in winter CET timezone, it has a default end date of 23:59:59. Since 23:59:59 is later than the CA's expiry time of 22:59:59 - the certificate becomes NOTRUST.
When Summer arrives again and CEST timezone takes effect (due to daylight savings), RACF will convert the "End Date" of 21:59:59 GMT to local 23:59:59 CEST.
Resolution:
This issue has been reported to development and an improvement was considered for a future WebSphere version. Until this improvement is available, newly generated certificates should be displayed at lease once to ensure they are in TRUST status, especially when a previously generated CA is being used. Definitely display the certificate if the CA was generated in a different timezone.
This issue has been reported to development and an improvement was considered for a future WebSphere version. Until this improvement is available, newly generated certificates should be displayed at lease once to ensure they are in TRUST status, especially when a previously generated CA is being used. Definitely display the certificate if the CA was generated in a different timezone.
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"","label":""},"Component":"","Platform":[{"code":"","label":""}],"Version":"","Edition":"","Line of Business":{"code":"","label":""}}]
UID
ibm11080579