Skip to main content

For businesses to secure the connections between applications, machines, and devices accessible via the internet, TLS/SSL protocols are used (note however that SSL is considered deprecated even though the name is still being widely used). These protocols rely on TLS/SSL certificates signed by trusted public certificate authorities (CAs). TLS/SSL certificates and the TLS/SSL protocols secure data by encrypting it and by authenticating communication parties in order to safeguard against tampering and malicious attacks on public websites.

What is a self-signed certificate?

A self-signed TLS/SSL certificate is not signed by a publicly trusted certificate authority (CA) but instead by the developer or company that is responsible for the website; as they are not signed by a publicly trusted CA, they are usually considered unsafe for public applications and websites.

The role of a public CA is to guarantee the validity of the information included in a certificate, especially the ownership and/or control of the domain name(s) associated with the certificate in the case of TLS/SSL. Therefore, using self-signed certificates is the equivalent of using credentials that have not been issued by a valid authority.

The expression “self-signed certificates” typically refers to TLS/SSL certificates that have been generated standalone, without any linkage to a root or intermediate certificate. This can also apply to other X.509 digital signing certificates such as S/MIME, code signing, and document signing.

The nature of self-signed certificates implies that the information on the certificate has not been verified by a trusted party (a public CA), and such certificates will trigger a security alert: Web browsers and operating systems will detect and flag certificates that have not been signed by a publicly trusted CA because they represent a security risk to their user: The certificate does not come from a trusted party, so it could be the work of an attacker deploying a man-in-the-middle attack.

These warning displays drive away users, fearing their personal or financial data to be at risk by interacting with your site.

How long are self-signed certificates valid?

By design self signed certificates – whether they're for TLS/SSL, S/MIME, document signing or code signing – can have any validity period because they are not subject to any regulation. They will however still need to be renewed and redeployed before they expire. The longer the validity period, the bigger the risk of forgetting about the certificate’s existence and its expiration date.

Unlike self-signed certificates, publicly trusted TLS/SSL certificates cannot be issued for longer than 13 months. Before 2015 the maximum validity period allowed was five years, but this was gradually reduced to 1 year. This applies to Extended Validation (EV) and Organization Validation (OV) TLS/SSL certificates.

Can self-signed certificates be trusted?

Using self-signed certificate means choosing to proceed without the support of a trusted certificate authority to guarantee the validity of the certificate details. By default, self-signed certificates will never be trusted by web browsers and operating systems. It is up to each user to bypass the security warning by manually approving each self-sign certificate they encounter, on each device they use, on a case-by-case basis. And warning messages make it clear that self-sign certificates can represent a security risk, so users are unlikely to proceed.

Are self-signed certificates secure?

Self-signed TLS/SSL certificates are flagged by browsers, because they are not issued by trusted CAs, so there is no guarantee that the certificate is legitimate. The browser displays a warning, stating that the certificate of the site is not issued by a trusted CA and therefore the connection is not guaranteed to be secure.

Security alerts from browsers and operating systems will deter an end-user from using the website or application as it feels unsafe and unsecure. That is why self-signed certificates are usually used for testing environments or low-risk internal networks only.

What is the risk of self-signed certificates?

Self-signed TLS/SSL certificates are safe in a testing environment, and you can use them while you are waiting for your certificates to be issued by a public CA. But, using them in a production environment will significantly decrease the traffic to your website or application and lead to a lack of trust from users.

Some organizations may find it interesting to use self-signed TLS/SSL certificates since they can be generated free of charge; however, what they often do not think about is the trust risks and the maintenance of self-signed certificates. Their renewal in particular can result in a lot of hidden costs.

A self-signed TLS/SSL certificate is signed with its own private key and is not chained to any intermediate or root CA. Self-signed certificates are created, issued, and signed by the company or developer responsible for maintaining the website that needs to be signed. While this could be a way to reduce costs on certificates for internal-facing websites, it is never a good idea for public websites and applications.

Exposure to vulnerabilities

Compromised private keys can be a major threat to the organization’s infrastructure. You can report compromised certificates to their issuing certificate authority and they will immediately revoke them. But for self-signed certificates, there won’t be any trusted revocation mechanism.

In addition, organizations often fail to keep a tab on their self-signed certificates, causing expired or compromised certificates getting overlooked or unnoticed. Such compromised certificates are the gateways for the malicious actors to gain access into the network and launch advanced and sophisticated malware attacks, man-in-the-middle (MITM) attacks, phishing attacks, and botnets.

No warranty and technical support

Public certificate authorities offer support, expertise, and management tools for their certificates. But for self-signed certificates, there is no support, expertise, or management tool provided as these certificates are generated in-house. You need human and financial resources to keep control of them.

Lack of visibility and control

Organizations use thousands of digital certificates, issued by both private and public CAs, and it is hard to track each of these certificates manually. Knowing how many certificates there are, who owns them, where they are located, and where the private keys are stored is pivotal in strengthening cyber defense.

Organizations using innumerable self-signed certificates often end up having blurred visibility into the certificate infrastructure. Unfortunately, if there is a breach in your organizational network, you would not know if it is caused due to a compromised self-signed certificate and private key associated with it.

Not meeting security requirements

Digital certificates issued by trusted certificate authorities maintain robust standards, whereas self-signed certificates are generated internally, and they are very rarely aligned with the latest security standards due to lack of knowledge and failure to keep up with best practices.

It is critical to manage and monitor all the digital certificates and keys existing within a corporate network. All certificates, both issued by CAs and self-signed certificates responsible for the functioning of internal and public sites, must be secured and protected and undergo constant monitoring.

For internal LAN-only services, you can use self-signed certificates, but you have to have a strong policy in place, to ensure that the issuing CA server is well-protected from cybercriminals and is located in a place that is not accessible by all the employees of your organization, and that you have monitoring tools and a team in charge of managing the certificate estate.