Getting Certificates for FTPS and HTTPS Endpoints

You have a transfer endpoint that needs a certificate — a new FTPS server for a partner, an HTTPS file drop for a department, a replacement for something expiring. The task sounds simple until you meet the questions: generate what, exactly? Send which file where? Public authority, the internal one the AD team runs, or just sign it yourself? One certificate for everything or one per host? And who renews it when it expires — because it will?

This article is the request walkthrough with the decisions attached. You will generate a private key and a certificate signing request the safe way, pick the right kind of issuer for each endpoint using an honest comparison, understand how authorities verify you, and set up the request so renewal becomes routine instead of archaeology. It is part of our Certificate Management series and assumes the vocabulary from certificates explained for transfer endpoints — leaf, chain, SAN. If those are fuzzy, start there.

What You Are Actually Requesting

A surprising amount of certificate confusion dissolves once you see who creates what. The certificate authority does not create your key. You do, on your own machine, and it never leaves. What you send the CA is a certificate signing request (CSR): a small file containing your public key, the names you want covered, and a signature made with your private key proving the request really came from the key's holder.

The CA's job is then narrow: verify you control the names, wrap your public key and names into a certificate, sign it, and hand it back. Three consequences follow, and each prevents a real mistake:

• The CA never needs, and should never receive, your private key. Any process that asks you to upload or email a private key is broken. The CSR exists precisely so the sensitive half stays home.
• The certificate you get back only works on a machine holding the matching key. A certificate file copied to a new server without its key is inert. Keep the pair together — and only the pair; the certificate is public, the key is not.
• Everything the certificate will say, you declare in the CSR. Wrong or missing names in the request become wrong or missing names in the certificate. The five minutes spent checking the CSR is the cheapest quality control in this whole process.

A useful mental model: the CSR is an application form plus a specimen signature. The authority checks the application, stamps it, and returns the stamped document. The pen you signed with — the private key — stays in your pocket.

Step by Step: Generate the Key and CSR

The OpenSSL toolkit is the lingua franca here — available on every platform, and its file formats are what CAs and servers expect. Windows admins can run the same commands, or use their platform's native request tools; the concepts are identical. The walkthrough below creates a key and a CSR for an endpoint reachable as both ftp.example.com and files.example.com:

# 1. Generate a new private key and a CSR in one step.
#    -nodes leaves the key unencrypted so the server service
#    can start unattended (protect the file instead - see below).
openssl req -new -newkey rsa:3072 -nodes \
  -keyout ftp.example.com.key \
  -out ftp.example.com.csr \
  -subj "/CN=ftp.example.com/O=Example Corp" \
  -addext "subjectAltName=DNS:ftp.example.com,DNS:files.example.com"

# 2. Read the CSR back and confirm every name is present
#    and spelled exactly right before sending it anywhere.
openssl req -in ftp.example.com.csr -noout -text

# 3. Restrict the key file to the service account that needs it.
chmod 600 ftp.example.com.key

# 4. Submit ONLY the .csr file to the certificate authority.
#    The .key file never leaves this machine.

Line by line, the decisions you just made:

• Key type and size. rsa:3072 is a solid, widely compatible choice; follow your security policy if it demands otherwise. The key is generated fresh — reusing an old key for a new certificate quietly extends the lifetime of anything that may have leaked.
• No passphrase (-nodes). A passphrase-protected key is safer at rest but means a human must type the passphrase at every service start — fatal for a transfer server that must survive an unattended reboot. The standard compromise is an unencrypted key defended by strict file permissions and a locked-down server, which is the approach covered in installing and chaining.
• The SAN list. The -addext line is the one that matters most. Every hostname clients will use must appear here, because validators match against this list. The -subj CN is largely ceremonial for modern clients, but keep it set to your primary name — some older systems still read it.
• The verification read-back. Step 2 is where you catch the transposed letter in a hostname before it becomes a certificate that fails name matching in production. Read the SAN line character by character.

Submission itself varies by authority — typically pasting the CSR text into a portal, attaching it to a ticket for an internal CA, or handing it to an automated protocol (below). The CSR contains nothing secret, so any channel is fine.

Choosing the Names: Exact, Wildcard, or Many

Before requesting, settle the naming question deliberately, because it decides how many certificates you manage and what breaks when things change.

List every name in use. Check DNS records, partner onboarding documents, and script configurations for the endpoint. If some clients reach the box as ftp.example.com and one legacy partner uses transfer.example.com, both go in the SAN list — or the legacy partner breaks the day you switch certificates. A multi-SAN certificate covering a handful of explicit names is the workhorse pattern for transfer endpoints.

Wildcards trade convenience for blast radius. A certificate for *.example.com covers any single-label host under the domain — handy when hosts come and go. The tradeoffs are real, though: the certificate (and its private key) tends to get copied onto every server that needs it, so one compromised box exposes a key valid for your entire namespace; and a wildcard matches only one level, so ftp.eu.example.com is not covered by *.example.com. A reasonable rule for transfer estates: wildcards for fleets of short-lived internal hosts, exact multi-SAN certificates for the small set of long-lived, partner-facing endpoints where you want the key confined to one machine.

One certificate can serve several protocols. FTPS and HTTPS are both TLS, so a server offering both can present the same certificate on each — one request, one renewal, provided the SAN list covers the names used for both services. Keep separate certificates only where different teams own the services or you want independent renewal schedules.

Public CA, Internal CA, or Self-Signed: The Real Choice

Every certificate comes from one of three places, and choosing well up front prevents the two classic mistakes: paying public-CA process costs for a lab box, and shipping a partner-facing endpoint that half your partners' clients refuse to trust.

The deciding question is almost always: who must trust this endpoint, and do you manage their machines? Partner-facing FTPS and public HTTPS answer "strangers," which means a public CA — you cannot install trust on machines you do not control, and asking partners to click past warnings is corrosive. Internal-only endpoints on domain-managed machines can use an internal CA cleanly, because your management tooling can distribute the internal root once and every internal certificate validates thereafter. Self-signed has a narrower legitimate niche than most people assume; the honest version of that niche, and the discipline it requires, gets a full article in self-signed and private CAs done responsibly.

How a Public CA Verifies You

Before signing, a public CA must verify you control the names in the CSR — otherwise anyone could request a certificate for your domain and impersonate you. For server endpoints this is domain validation: the CA issues a challenge only the domain's controller can answer, typically one of:

• A DNS challenge — publish a specific record under the domain; the CA looks it up.
• An HTTP challenge — place a specific file at a well-known path on the name's web server; the CA fetches it.

Some certificate types add organizational vetting on top (verifying the company itself, not just domain control). For transfer endpoints the machine on the other side is usually a script or client that checks chain, dates, and names — the checks described in certificates explained — so domain validation is generally what matters; buy more ceremony only when a partner's compliance regime demands it.

The practical planning note: challenges assume you can edit public DNS or serve a file on the validated name. For an FTPS server with no web server on it, the DNS challenge is usually the smooth path. Loop in whoever controls your DNS before the request, not during the outage window.

Automating Issuance and Renewal: The ACME Idea

Modern public certificates have short lifetimes, and the direction of travel is shorter still. That is deliberate: short lifetimes limit how long a stolen key stays useful and force rotation to be routine. The consequence for you is blunt — manual renewal does not scale anymore. A process that relies on a human remembering is a process that fails at the worst moment, which is the entire subject of certificate expiry monitoring.

The evergreen answer is ACME — the Automated Certificate Management Environment, a standard protocol in which a small agent on your side generates the key and CSR, completes a domain-validation challenge automatically, retrieves the signed certificate, and repeats the whole cycle before expiry with no human involved. Most public CAs and many internal CA platforms speak it. The concept matters more than any particular client: issuance and renewal become an unattended, verifiable loop rather than a calendar entry.

For transfer infrastructure there is one wrinkle worth planning for: ACME agents grew up around web servers, and your FTPS service is not one. Two patterns bridge the gap:

• Validate via DNS, then deploy. The agent uses the DNS challenge (no web server needed), and a post-renewal hook copies the new key and certificate to wherever the transfer service loads them, then reloads the service.
• Terminate names on one front door. Where an HTTPS front end already holds the certificate for a name, transfer services behind it can share the automated renewal rather than running their own.

Whatever the mechanics, the test of your automation is the same: the new certificate must end up being served, not just issued. A renewed file sitting next to a service still presenting the old one is a common and embarrassing outage. Automation should end with a verification step against the live endpoint — the outside-in check from installing and chaining — not with the download.

What Comes Back, and What to Do With It

The CA returns your leaf certificate, usually alongside the intermediate certificate(s) needed to chain it to a trusted root — sometimes as separate files, sometimes as one "full chain" bundle. Keep everything; the intermediate is not packaging filler, it is the piece whose absence causes the classic "works in a browser, fails in the transfer client" misinstall.

Formats you will meet, so none of them rattles you:

• PEM — text files beginning -----BEGIN CERTIFICATE-----. The common currency; certificates and keys travel as separate files. Extensions vary: .pem, .crt, .cer, .key.
• DER — the same content, binary. Some tooling produces it; convert to PEM when in doubt.
• PFX / PKCS#12 — a single password-protected container holding certificate, chain, and private key together. The customary format on Windows, where server software typically imports one PFX rather than three loose files.

From here the work is installation: assemble the chain in the right order, put the key where the service can read it and nobody else can, bind the certificate to the service, and verify from the outside like a client would. That is the next article, installing certificates and getting the chain right. On a Windows transfer server such as Sysax Multi Server, which serves FTPS and HTTPS using the certificate you configure, the request-side work in this article is identical — generate the key and CSR, get the leaf and chain back — and installation is where the platform's conventions take over. Protocol-specific color for the FTPS case lives in our FTPS certificates article.

A Request Checklist to Reuse

The whole article in one reusable list — worth pasting into your runbook:

1. Inventory every hostname clients use for this endpoint; decide exact SANs vs wildcard deliberately.
2. Choose the issuer by audience: strangers → public CA; managed internal machines → internal CA; lab or pinned automation → self-signed, with eyes open.
3. Generate a fresh key on the destination machine; never reuse or transmit it.
4. Create the CSR with the full SAN list; read it back and verify every name.
5. Confirm you can answer the CA's validation challenge (DNS access or HTTP path) before submitting.
6. Decide the renewal mechanism — ACME agent, internal CA auto-enrollment, or a monitored manual runbook — and write down the owner.
7. Receive leaf plus intermediates; store them with the key, and record the expiry date in your certificate inventory.

The Version to Tell a Colleague

Getting a certificate is three moves. You generate a private key and a CSR locally — the CSR carries your public key and every hostname in the SAN list, and the private key never leaves the machine. You pick the issuer by who must trust the endpoint: public CA for anyone you do not manage, internal CA for managed internal machines, self-signed only for labs and tightly controlled automation. And you decide at request time how renewal will happen, because modern certificate lifetimes are short by design and manual memory is not a renewal strategy. The CA verifies you control the names, signs, and returns your leaf with its chain — at which point the job becomes installation, which has its own classic pitfall and its own article.

Continue with installing certificates and getting the chain right, then close the loop with certificate expiry monitoring so this certificate never becomes a surprise.

Frequently Asked Questions