A digital certificate gives information that is identifying and forging it is hard as it issued and its verification is done by official and trusted agency. What is in the certificate is the name of the holder, a serial number, the certificates holders key copy and expiry dates as well as a digital signature of the certificate issuing authority (CA). The certificate is signed by root certificate digitally that belongs to a certificate authority that is trusted so as to give evidence that the certificate is valid and genuine. A list of trusted CA certificates is kept by the operating systems and browsers so that they can verify certificates easily.
The major concern and weakness of the digital certificates is the security the certificate authorities (CA) such as VeriSign and Network Solutions offer. The issue is that CAs can get compromised; there exists examples such as the DigiNotar and DigiCert which goes to show that attackers are going for the CAs. Microsoft has admitted to its system being able to be compromised, its internally issued certificates were taken control of and a man in the middle kind of attack was that led them to take control several computers and put in them the flame malware. Poor management is what caused the Microsoft to succumb to such vulnerability due to using certificates signed with weak algorithms.
Sometimes, cyber-criminals succeed in penetrating a corporate network and gaining access to a private key used to sign files. With that key, they can sign any malicious file and pass it off as a file produced by a legal software manufacturer. The stealing of the private key is another vulnerability and it is done by installing a special malware, once the key has been stolen, cyber-criminals sell the keys to other users, if the key is stolen from a famous software manufacturer it can easily be bought by people in other firms without trying to verify it.
Vulnerabilities exist in algorithms that are used to check file signatures to be executed. Operating systems need to find the part of the file that has information on the presence of a digital certificate, to do that a header of each file must contain 8 bytes of data about the location and size of the digital certificate. When doing the checks, most operating systems ignore the 8 bytes when doing the checks which leads to signatures being signed by weak algorithms. There also exist weak controls over use of the signing keys which enable the digital certificates to get misused and get compromised.
All digital certificates contain an expiry date which is often set two or three years from the date it is issued. Once expired, the firm has to obtain a new one but organizations can revoke certificates at any time and some of the reasons include, stealing of a private key that corresponds to the certificate or the change in the domain name has changed or is no longer in service. When administrators realize that the key may have been compromised, they can request that the issuance of the CA be revoked to prevent the clients from accessing a compromised server.
Once a certificate has been revoked it is put in the certificate revocation list (CRL) which just like other blacklists are hard to maintain and is not efficient in dispersing information that is critical on a real time basis. When a browser sends a request of CRL to a CA, the CA sends a list of all the revoked certificates it manages, the browser is then tasked with parsing the list to determine if a particular certificate has been revoked. Although CRLs are updated almost hourly, the small time gap may allow a revoked certificate to be used somewhere. If the CRL is not available, acceptance of the certificate will be delayed causing a temporary denial of service.
The solutions to problems of revocation are to do proper checks on certificates that have been revoked. The information on certificate revocation should be accessible to all users and should open for users to see certificates that have been revoked. The methods to check certificate validity should be made available by KPI. Applications should not open once revocation status of certificates cannot be accessed. The other way to solve the problems of revocation is to revoke only certificates that are no longer in use and that are no longer needed. The reason is because revocation does not automatically work because checking applications meant to check might not be able to open. Also when employees get fired or lose their jobs, their accounts get automatically deleted which works better than carrying out revocation of certificates.
The deletion of accounts of employees is better than having a revocation list. The revocation lists get longer and cause network problems to their accounts. So if revocation is done all the time, the lists will become longer which are not necessary. There is an alternative to using the CRL which is the online certificate status protocol. Instead of downloading the current CRL to check whether a certain URL is on the list, the browser sends the request of the certificate to the certificate authority and it simply returns good or revoked or unknown which saves the time that is used in parsing and also less data is transferred in the process.