Free PKI and Certificates practice questions

Basic constraints marks a certificate as a CA with CA:TRUE or as an end entity with CA:FALSE, and a CA:FALSE certificate can't sign other certificates. The Subject Alternative Name lists the names a certificate covers, the serial number identifies it for revocation, and the validity period sets when it is accepted.

PKCS #12 files with a .pfx or .p12 extension bundle a certificate with its private key and need the same protection as a password, so only the certificate itself should be shared. A certificate is public by design and is handed to every client that connects, so sharing it is harmless; email doesn't alter it, and the partner has no reason to request a certificate of its own.

Whoever controls a root in a device's trust store can issue a certificate for any name and the device will accept it, which lets an attacker intercept encrypted traffic without warnings; some malware adds roots for exactly this reason. A trust store entry doesn't change certificate dates, switch off revocation checks or expose the laptop's private keys.

An offline root still publishes a revocation list with an expiry date, so someone must power it on to re-sign the list before it lapses, and systems that demand current revocation data fail until that happens. Leaving the root online permanently exposes the PKI's most valuable key, reissuing certificates doesn't renew the root's CRL, and disabling revocation checks removes a security control.

Trust stores differ by platform: Group Policy adds the root to the Windows store, but Java applications often ship with a separate cacerts file, so the same chain can validate in one application and fail in another on the same machine. The server already sends its intermediate, a SAN problem would break the browser too, and every root certificate is self-signed by design.

Self-signed certificates encrypt as well as CA-issued ones but give clients no identity assurance, so they fit labs, development and test systems that only their builders use. Customers and partners need a public CA, and an internal site used daily needs a certificate from an internal CA whose root is pushed to company devices, so employees don't learn to click through warnings.

Domain validation only confirms control of the domain, is automated, takes minutes and is often free. OV and EV add checks of the organization's legal identity that usually take days, and a self-signed certificate isn't publicly trusted at all. All of them encrypt equally well; the validation level changes the vetting, not the encryption.

Every server holds the same private key, so the least protected machine holds a key that can impersonate www, mail and every other subdomain, and revoking it takes every site down at once. Wildcards actually keep individual hostnames out of Certificate Transparency logs, browsers don't care how many servers share a certificate, and the encryption is the same as any other certificate's.

The extended key usage field states what a certificate may do, and software that checks it refuses a certificate presented for any other purpose, so a TLS server certificate can't sign code. Who issued the certificate doesn't change what it may be used for, SAN lists hold names such as DNS names rather than file names, and ECDSA is a current signature algorithm.

Public CAs record every TLS certificate in Certificate Transparency logs, so any certificate naming launchpad.example.com makes the hostname searchable. A wildcard publishes only *.example.com, which still covers that single-level name. A SAN entry, an EV certificate or the common name of an OV certificate all publish the name, and EV certificates can't be wildcards anyway.