SSL Registration: Why It's Really Issuance, and How Certificates Actually Get Installed

SSL registration is not a real technical step; what people mean is certificate issuance — a certificate authority verifying you control a domain and issuing a signed certificate for it, either a free automated one through ACME (the protocol behind Let’s Encrypt) or a paid one with organization or extended validation for a business that needs it verified. Nothing gets registered with a central registry. You generate or automatically create a request, a CA checks it, and a file comes back that your server presents to visitors. On a managed host, this entire sequence is invisible and automatic.

The phrase persists because it sounds like something bureaucratic you file once, and the top results lean into that: certificate authority sales pages promising a fast registration process, alongside generic explainers that use get, register, and install interchangeably without ever separating them. They are three different steps with three different owners, and knowing which is which is what makes a certificate error make sense instead of feeling random.

Table of contents

• The three steps hiding behind the word ‘registration’
• DV, OV, and EV: what’s actually being verified
• The CSR, and the automation that replaced it
• Installing and renewing: where it actually breaks
• A quick way to check a certificate right now
• What happens on a managed host
• How this fits the rest of the stack
• FAQ

The three steps hiding behind the word ‘registration’

Issuance, installation, and renewal are separate operations, done by different parties, and conflating them is why certificate problems feel confusing.

1. Issuance. A certificate authority verifies you control the domain (or, for paid tiers, your organization) and signs a certificate.
2. Installation. The certificate and its private key go onto the server that terminates TLS — your own box, a load balancer, or a managed platform’s edge.
3. Renewal. Certificates expire, typically in 90 days for free automated ones or a year for paid ones, and have to be reissued and reinstalled before they do.

Registering an SSL certificate usually means all three, done manually, once, by someone who then forgets step three exists until a browser warning appears.

DV, OV, and EV: what’s actually being verified

The three tiers differ only in what the CA checks before issuing, not in the strength of the encryption — a DV and an EV certificate both use the same TLS.

• Domain Validation (DV). The CA confirms you control the domain, usually via a DNS record or a file at a specific URL. Fully automatable, free through Let’s Encrypt and similar CAs, and sufficient for the overwhelming majority of sites.
• Organization Validation (OV). The CA additionally verifies the requesting organization is real, through business registration records. Takes longer, costs money, mostly relevant to enterprise procurement checklists rather than visitor trust.
• Extended Validation (EV). The most thorough vetting, historically shown with a green address bar. Browsers stopped visually distinguishing EV years ago, which removed most of its practical benefit.

For nearly every website, DV through an automated CA is the right and sufficient choice.

The CSR, and the automation that replaced it

The traditional path: generate a private key and a Certificate Signing Request (CSR) containing your public key and domain name, submit the CSR to a CA, prove domain control, receive a signed certificate, install it manually.

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key -out example.com.csr

ACME, the protocol behind Let’s Encrypt, automates the entire loop: a client on your server proves domain control programmatically, requests and receives the certificate, and can reinstall and reload the web server automatically. Certbot is the most common ACME client for a self-managed server; most managed platforms run the equivalent flow internally with no client for you to install at all.

The practical shift over the last decade is that manual CSR submission has gone from the default to the exception, reserved mostly for OV/EV certificates that still require a human review step the automation cannot skip.

Installing and renewing: where it actually breaks

Issuance rarely fails silently. Installation and renewal do.

• Wrong certificate chain. The server presents the leaf certificate without the intermediate, which passes in some browsers and fails in others depending on how they build the trust chain.
• Renewal timer that stopped firing. A cron job or systemd timer for certbot renewal that silently broke after an unrelated config change is the single most common cause of an expired-certificate outage.
• Certificate and key mismatch after a manual reissue, when the new certificate gets installed against the old private key.

Check a renewal timer actually exists and actually ran recently, rather than assuming it works because it worked once.

A quick way to check a certificate right now

Two commands answer most ‘is my SSL working’ questions without touching a dashboard.

curl -vI https://example.com 2>&1 | grep -A2 'SSL certificate'
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates

The first confirms the handshake succeeds at all. The second prints the exact expiry date, which is the number that matters when a renewal timer is in question — if it is inside thirty days, treat it as urgent regardless of what the timer is supposed to be doing.

What happens on a managed host

On a static site or web service on a platform like RunxBuild, this entire sequence disappears from your task list. Point the custom domain, and the certificate is issued through an automated DV flow, installed at the edge, and renewed on schedule with no timer for you to check.

That is the actual value of managed in this specific context: not that the certificate is somehow better, but that steps two and three, the ones that silently break, are no longer yours to maintain.

How this fits the rest of the stack

Whatever you call the process, the outcome that matters is the same: a valid certificate installed on the right server and renewed before it expires. On a static site or web service on RunxBuild, that whole sequence runs automatically once a custom domain is pointed at it — no CSR, no renewal timer, no expired-certificate outage at an inconvenient hour. See custom domains and certificates on RunxBuild for how that works. If you are pricing what sits behind the domain, the RunxBuild hosting calculator puts the service, storage, and bandwidth on one screen, and the dashboard is where the domain gets added.

Useful related references:

• How to Renew an SSL Certificate: A 2026 Guide
• Unlimited SSL: What That Phrase Is Actually Selling
• What Does SSL Mean? And Why Nobody Actually Uses SSL Anymore
• Custom domains and certificates on RunxBuild

FAQ

Is ‘SSL registration’ the same as getting a certificate?

Yes — there is no separate registration step. What people call SSL registration is certificate issuance: a certificate authority verifies domain control and signs a certificate. Installing it on your server and renewing it before expiry are two further, separate steps that the word registration tends to hide.

Do I need a paid SSL certificate, or is a free one enough?

For most sites, a free domain-validated certificate through an automated CA like Let’s Encrypt provides identical encryption to a paid one. Paid organization- or extended-validation certificates verify your business identity for procurement or compliance reasons, not stronger encryption, and browsers no longer visually distinguish them.

What is a CSR and do I still need one?

A Certificate Signing Request bundles your public key and domain name for submission to a certificate authority. Automated ACME clients generate and submit it for you invisibly. You still handle a CSR manually mainly for organization- or extended-validation certificates, which require a human review step automation cannot complete.

Why did my SSL certificate expire without warning?

Almost always a broken renewal timer: a cron job or systemd timer for a tool like certbot that stopped firing after an unrelated server change. Check that the timer exists and ran recently rather than assuming automation is working because it worked when it was set up.

Does a managed host handle SSL certificate registration for me?

Yes. On a managed static site or web service, pointing a custom domain triggers automated issuance, installation, and renewal with no certificate authority account, CSR, or timer for you to manage. That automation is the actual benefit of managed hosting in this context.