What is a Certification Authority (CA) in the Captive Portal / SSL Forward Proxy context, and what is the difference between the CA cert and the leaf cert it signs?

A CA is an entity that issues (signs) certificates. The CA cert is a self-signed root; leaf certs are signed by the CA and identify specific services.

* The CA hierarchy: one self-signed root (trusted once on the client) signs many leaf certs. *

Hierarchy on the firewall:

1. fw01.mydomain.ch — the firewall's own root CA. Self-signed (the Signed By field is left empty), so the certificate is its own issuer. This is the cert you install into the client's Trusted Root store. Trust it once → trust everything it signs.
2. captiveportal — a leaf cert with Common Name captiveportal.mydomain.ch, signed by the root CA. Used by the Captive Portal HTTPS service.
3. (Optional) more leaf certs for other internal services, all signed by the same CA.

Why two layers?

• You install the CA cert on every client once.
• The CA can then sign as many leaf certs as needed without further client touch.
• Compromise: leaf cert leak ⇒ revoke just that cert. CA cert leak ⇒ disaster (every cert ever signed becomes trustable forgery material).

Cert attributes that must match exactly:

• Common Name (CN) = service hostname / FQDN. The Common Name and certificate attributes must be typed exactly right (captiveportal.mydomain.ch) or the cert is invalid.
• Subject Alternative Name (SAN) = same hostname. In modern public PKI, browsers increasingly validate the hostname against the SAN rather than the legacy CN, so production certs should carry the FQDN in the SAN too.

Tip: Public web CAs (Let's Encrypt, DigiCert) are just bigger versions of this. Same model, more clients, more scrutiny.

Go deeper:

• Certificate authority (Wikipedia) — root vs. leaf certs, the signing hierarchy, and why a root compromise is catastrophic.