How To Check Symantec License Expiry Date

[Paskasi Coppola]

Authorizationcertificates are an important part of system security. For example, a certificate is used to secure the communication between a Pega application running in a browser and Pega Robot Runtime. These certificates expire and you might need to check the expiration date of a certificate. Perform the following steps to check the expiration date of a certificate:

Not sure why, but when using Code Signing using symantec's timestamp server it sets the expiration for the year 2020. This defeats the purpose of using a timestamp server if my program is still going to expire.

Please note that this certificate is set for 1 year expiry, so it is using a timestamp from the server that Symantec provides. According to the (limited) documentation on this subject, using a timestamp server when signing an application should eliminate the application from expiring after the certificate has expired. According to the information I see above, this is not the case as my application will stop functioning on Tue Dec 29 19:59:59 2020.

The purposes of using time stamping is not to make your signature valid forever. Its purposes it to extend the useful life of your signature, from the usual 1 to 3 years that code-signing certificates are valid, to up to 10 years. This is long enough for most needs -who really thinks their code will be traveling through insecure networks (and therefore in need of code signing)and executing 10 years from now.

A time stamping service does nothing more than signing a hash of your own digital signature, plus the current time (as provided by the time stamping service) with the time-stamping sevice's certificate which they (hopefully) guard a lot better than most users of digital certificates and which has been therefore granted a much longer shelf-life. Long-lived as they are, they are still just digital certificates and for basic security every one of those eventually must expire. Given that computers keep getting more powerful even the most secure algorithms and longest signing keys supported today will eventually be insecure.

Note that the expiration date is nothing more than the longest time a certificate (either your code signing one or the time-stamping one) could be valid for. Even today some time-stamping servers use SHA-1 for signing (e.g. that is what your time-stamping example is using). When that algorithm is no longer trusted (and it shouldn't be too long now), all those SHA-1 time stamps will no longer be trusted. That will happen even if the expiration date hasn't been reached.

I can verify from my painful experience today: an expired timestamp certificate (in my case, Comodo's timestamp cert) will cause Windows (7) to fail the overall code signing check with error 0x80096005, which means this:

Why would it stop functioning? Have you tried it? Try to set date on your computer to 2021 and see what happens. Personally I have not tried it but my colleague did. Windows will still run the program. It will validate the application to the date of signing. TSA server certificate was valid then so it should not be a problem.

If you wouldn't have timestamp on the application's signature that would be a problem. After the certificate of signer expires windows will not run the application. But when using timestamp windows does not care about expiry date of TSA certificate.

Following the investigation documented below, a consensus proposal was reached among multiple browser makers for a graduated distrust of Symantec roots. The dates in that proposal and how they apply to Mozilla's Root Program and Firefox are as follows:

This page lists all confirmed issues involving the CA "Symantec". It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, email Wayne. Information here is correct to the best of Mozilla's knowledge and belief. Symantec has also confirmed the accuracy of the information, although errors transcribing their statements into this page remain Mozilla's.

Symantec issued a cert to one of its customers that did not comply with at least one provision of both the CA/Browser Forum Baseline Requirements and Mozilla policy. It was a 1024-bit cert which expired after the end of 2013. Symantec believed this was the only technical way to ensure continuity of service for the customer concerned.

This cert was issued directly from the root. Symantec's write-up points out that issuance from the root is permitted by BRs version 1.1.6, the version in force at the time, if 5 conditions are met, and they say they were met.

The cert had a short serial number. Entropy in the serial number is a SHOULD in BRs 1.1.6. 20 bits of entropy is a MUST in the Mozilla policy (version 2.2), but it doesn't say it has to be in the serial number - it could be that they randomised the notBefore time. I am told Microsoft removed the allowance for doing entropy in the Date field on 11th November 2013, so this was a violation of their policies. Symantec say that they got a verbal exception from Microsoft.

Symantec did not request permission to issue in advance, they disclosed the issuance at least a month after it had happened, and the replacement certificate (unlike the original) asserted a "BR Compliant" OID.

Symantec self-reported this issuance to Mozilla via Bugzilla at the end of January 2014. Even though a question was asked about the BR Compliance OID that the new cert asserted, they did not comment on the bug beyond the initial report. Recently, Symantec have produced a longer write-up of the incident.

Given that we did not query it at the time, we must accept that the BR criteria for direct issuance from the root were met. The Mozilla policy does not include the exceptions directly, but does reference BRs chapter 12, and so could be said to include the exceptions by reference.

The issuance of a 1024-bit cert expiring after the deadline was both a BR and a Mozilla policy violation. Symantec say: "we did not engage the broader browser community due to the time pressure around the holiday." This seems like a weak excuse.

Symantec have stated that their four RA partners (CrossCert, CertSuperior, Certisign and Certisur) had the technical ability to issue EV certificates despite not having EV audits for their operations. Symantec does not directly state so, but it is assumed that, given the lack of audits and the infrequency of occurrence (normal process was for them to pass EV request information on to Symantec) that the RAs were not authorized to make such issuances. However, three of those organizations did so on a number of occasions. Looking at the dates, this appears to have happened in two successive audit periods.

Symantec says that they revalidated the EV information used to issue the certs once they discovered the issuance, and that the validations met the EV authentication guidelines. However, it seems that they did not implement technical measures to prevent further occurrences. Symantec discovered all this before the recent investigation, but did not disclose these events to Mozilla as misissuances at the time.

Between 2009 and 2015, Symantec issued a large number of test certificates in their publicly trusted hierarchies. These contained domains that Symantec did not own or control, and for which domain validation was not performed. Some of these domains were unregistered, and others were owned by other organizations. Issuing test certificates for unregistered domains was not a BR violation before 3rd April 2014 (ballot 112), because they counted as Internal Server Names, but they continued the practice even after that date. The registered domains used included those belonging to Google and Opera Software. Given the numbers involved, this sort of test certificate issuance appears to have been common practice at Symantec. Some of the test certificates (including one for www.google.com) left Symantec's network because they were logged in CT. (Symantec claim that no certificates left their network; however, it's not clear how this can be true, and clarification is being sought.) However, Symantec personnel would have had access to the public and private keys of the certs.

It took quite a while for the full scale of the problem to emerge, and Symantec had to publish numerous updates to their "Final Report". Symantec released a number of documents relating to this - Final Report, Final Report v2, Final Report v3, list of certs containing owned domains, list of certs containing unregistered domains, further update. They also issued a blog post, "A Tough Day As Leaders", which is no longer on their website but has been archived. It indicates that 3 employees were fired as a result of the misissuance. They posted another page with "complete investigation results".

We have identified three root causes underlying the mis-issuance of these test certificates. First, we continued to issue internal test certificates to unregistered domains after the April 2014 change in the Baseline Requirements that removed authorization to do so. The overwhelming majority of the mis-issued test certificates fall into this first category. Second, certain Symantec Quality Assurance (QA) personnel had systems access, including the ability to use certain legacy tools, which enabled them to request a limited number of test certificates that were issued without review by authentication personnel. Third, authentication personnel did not consistently follow all verification steps when they received test certificate requests from their Symantec colleagues, or requested test certificates themselves.

In October 2015, it was discovered that Symantec's DV certificate products (e.g. RapidSSL, QuickSSL) had a flaw when parsing email address data from WHOIS, in that they did not parse + and = characters correctly. This meant that, in cases where the domain owner had used these characters, the address as parsed by Symantec was not the one the domain owner had inserted, and if other email addresses of a particular form could be registered at that domain, there was a possibility that an attacker could get a cert for the domain.

3a8082e126