A self-signed certificate is a digital certificate that is signed by the same entity that created it, rather than by a trusted Certificate Authority. This means there is no external verification of the certificate holder’s identity, and the certificate is not automatically trusted by web browsers or operating systems. These types of certificates are often used in development environments or for internal network services where trust is established manually. In contrast, a certificate issued by a recognised CA undergoes a verification process before being signed, and because the CA is already included in the system’s trusted root certificate store, the certificate is immediately trusted by clients. The critical difference lies in the trust chain: a CA-issued certificate forms part of a hierarchy of trust that is recognised by most systems, whereas a self-signed certificate requires manual configuration and carries a higher risk of being spoofed or misused in a real-world environment.

Wildcard certificates and SAN (Subject Alternative Name) certificates are both used to secure multiple domain names, but they serve different purposes and have different formats. A wildcard certificate secures a single domain and all its subdomains using an asterisk in the domain name, for example, *.example.com. This would cover www.example.com, mail.example.com, and blog.example.com, but not example.co.uk or sub.mail.example.com. Wildcard certificates are useful when managing multiple subdomains under one main domain. SAN certificates, on the other hand, allow the inclusion of multiple specific domain names and subdomains in one certificate. For example, a SAN certificate could cover example.com, example.net, shop.example.com, and mail.anotherdomain.com. They are particularly useful for organisations hosting several domains on the same server. SAN certificates provide more flexibility across different domains, while wildcard certificates are limited to one domain and its direct subdomains. Choosing between the two depends on the number and structure of domains needing coverage.

When a Certificate Authority is compromised, it means that an attacker has either obtained the CA’s private key or found a way to issue fraudulent certificates without proper validation. This poses a serious threat to internet security because the attacker can impersonate any website, issue certificates to malicious actors, and intercept or manipulate data in transit under the appearance of a trusted identity. If such a breach is discovered, browser and operating system vendors immediately remove trust for the CA’s root certificate from their trusted certificate stores. This renders all certificates issued by that CA invalid. Websites using certificates from the compromised CA must obtain new certificates from a different trusted CA. In addition, the compromised CA may be permanently shut down or required to revalidate its security procedures. This situation highlights the critical role of maintaining CA security and the need for mechanisms like Certificate Transparency to monitor all issued certificates for signs of misuse.

Certificate chains and intermediate certificates exist to create a hierarchical structure of trust from a root Certificate Authority down to the end-entity certificate (such as a website’s certificate). A root certificate is self-signed and preinstalled in trusted certificate stores on systems. However, issuing every certificate directly from the root would be risky; if the root were compromised, every certificate would be at risk. Instead, root CAs delegate trust to intermediate CAs, which issue certificates to end entities. This creates a chain of trust: end-entity certificate → intermediate certificate(s) → root certificate. During a secure connection, the server sends its certificate and the intermediate certificate(s) to the client. The client uses the chain to verify the signature all the way up to the root. This structure improves security and scalability by isolating the root and limiting exposure, allowing CAs to revoke intermediate certificates if needed without affecting the entire ecosystem of trusted communication.

Certificate pinning is a security technique used to protect applications and services against man-in-the-middle (MITM) attacks by specifying exactly which certificate or public key is expected from a server. Instead of trusting any certificate signed by a recognised Certificate Authority, the client application is configured to accept only a specific certificate or public key when communicating with a particular server. This prevents attackers from using a compromised or fraudulent certificate, even if it appears valid and is signed by a trusted CA. There are two main types of pinning: static pinning, where the expected certificate is hardcoded into the application, and dynamic pinning, where the certificate is learned and cached securely during the first successful connection. While pinning significantly enhances security, especially in mobile apps and banking systems, it can also cause disruptions if certificates are renewed or changed and the application is not updated. Therefore, pinning must be carefully managed to balance security and reliability.