SSL Certificates on Access Server's Web Services⁠

SSL secures HTTP⁠

SSL stands for Secure Sockets Layer. It's an add-on to an existing system: hypertext transfer protocol (HTTP).

Web browsers transfer information from a web server to your computer in the browser using HTTP. Access Server's web server displays in your web browser this way, giving you the Admin and Client Web UIs.

HTTP alone is insecure. Anyone intercepting traffic between your browser and a web server can see everything flowing over the network. This is especially insecure when visiting sites like banks or financial institutions.

Therefore, we add a security layer, SSL, and HTTP becomes HTTPS, a secure version of HTTP.

SSL sets up an encryption layer so everything flowing over the connection is unreadable to outsiders. This is done using a clever system using prime numbers and mathematical calculations that make it impossible for anyone trying to intercept the traffic to see what's going through the encryption connection.

SSL establishes trust⁠

Encryption alone isn't the only purpose; another essential SSL certificate purpose is establishing trust.

You can trust the server you are connecting to if it's verified to be the server you think it should be. The SSL certificate determines the server's identity and holder of the private and public keys.

An SSL certificate has two major components: a private and a public key.

The server generates the private key, which stays with the server. It stays private. It's used to create a certificate signing request (CSR). The CSR is a standardized form with identifying questions like your website's common name, your contact details, where you are located, etc. After answering the questions, a file connected to the private key cryptographically without containing the key itself is generated. The CSR is sent to a certificate authority (CA).

A CA confirms and validates the identities of website owners so they can issue public certificates with their keys. Root authorities trust these keys, and web browsers and SSL-capable programs automatically trust root authorities' keys and certificates.

Certificates work with a hierarchy: the SSL certificate chain. The SSL certificate on your website (your end-user certificate) includes a chain that starts with your issued certificate and then identifies the certificate above it, an intermediate certificate. There may be several intermediate certificates in the chain, and at the top is the root certificate.

Installing your end-user certificate must include all intermediate certificates, or it isn't trusted. This is because it's seen as a broken or invalid chain.

SSL keys⁠

The SSL certificate chain means that a web browser sees your public key (the end-user certificate) as trusted when it finds the root authority certificate at the top of the chain. Thus, the private key you get from the CA is also trusted.

This signed key is a public key cryptographically tied to your private key without containing the private key. The public key, stored on the web server, is shared publically, while the inextricably linked private key remains private.

Anytime someone visits your website, the web server shares a copy of the public key.

Think of it like showing your passport to someone who needs to confirm your identity. Your passport shares public details about you, including information like the country and authority that issued it. Only a trusted authority can issue a passport; only they know your private information, like where you were born, where you live, etc. This is like a CA that issues you your certificate. Any browser seeing the SSL certificate can check with the CA to see if it's real.

The link between the public and private keys provides security. If a visitor receives the public key and checks with the CA before trusting it, it can be taken further: Does this web server presenting the public key also hold its linked private key?

If not, they're faking it. This needs to be tested.

Modern passports include biometric data for added security.

Likewise, anything encrypting using the public key can only be decrypted by the holder of the private key linked to it. So, by sending information encrypted with the public key and receiving a sensible response, you can be sure it's the correct web server. Only the private key used to create the original CSR, approved and signed by a certificate authority, can decrypt data encrypted with the linked public key.

That's your proof of identity and method of establishing trust. That's a simplified overview of how SSL certificates secure internet traffic by ensuring you're connected to the correct web server.