Your managed entry point serves TLS with a certificate the platform issued, so who keeps it valid, and what changes if you upload your own?

## Terminating with a certificate you did not create A managed entry point is where public TLS ends for most rented front doors: the client's encrypted connection is terminated at the platform's pool, and the platform needs a certificate to present. What makes this a platform question rather than a protocol question is **custody and lifecycle** — who obtains the certificate, who holds the private key, who renews it, and who gets paged when it expires. The protocol mechanics of the handshake, and which legs of the path stay encrypted afterwards, are a separate subject owned elsewhere. There are two arrangements, and every provider offers some form of both. ## The platform-issued certificate You name the public name the entry point will serve, and the platform obtains a publicly trusted certificate for it. Before it can, you must **prove control of that name**, typically by publishing a value the platform gives you at that name, or by pointing the name at the entry point so the platform can observe it. Once issued, the platform installs the certificate on the entry point and renews it ahead of expiry on its own schedule. The important detail is that renewal is not unconditional — it is **revalidated**. The platform periodically re-checks that you still control the name, and if the proof was removed, renewal fails. The failure is quiet, because nothing is broken yet: the current certificate is still valid for weeks or months. The outage arrives later, when it expires, usually well after whoever removed the record has forgotten doing it. The private key for a platform-issued certificate normally stays inside the platform and cannot be exported. That is a security property, not an oversight, but it means the certificate cannot be reused on anything outside that platform. ## The certificate you bring Here you obtain a certificate yourself, from whatever issuer your organisation uses, and upload it to the entry point along with its private key. The platform serves it faithfully and does nothing else: it will not renew it, will not warn you meaningfully as expiry approaches on some platforms, and will keep presenting it after expiry, at which point every well-behaved client refuses the connection. | | issued by the platform | brought by you | |---|---|---| | who obtains it | the platform, after you prove control of the name | your team, from your issuer | | who renews it | the platform, while the proof still holds | nobody unless you build it | | where the private key lives | inside the platform, usually not exportable | wherever you generated it, plus the platform | | usable outside this platform | usually not | yes | | what expiry looks like | a renewal that silently stopped working | a date nobody owned | ## The failure modes worth naming - The validation proof is deleted during unrelated housekeeping, renewal stops, and the outage lands a quarter later. - A new public name is added to the entry point and nobody proves control of it, so it is not covered. - An uploaded certificate is replaced in one environment and forgotten in another. - The chain is incomplete: the certificate is fine but an intermediate is missing, so some clients reject it while browsers, which fetch missing intermediates, do not. - The certificate is fine everywhere and the outage is the **private** leg instead, where a self-signed certificate behind the door expired without anyone tracking it. ## What to monitor, whichever arrangement you use 1. **Remaining validity measured from outside**, against the live entry point, not against a file in a repository. That is the only measurement that reflects what clients actually receive. 2. **Renewal events in the platform's audit record of management calls**, so a renewal that stopped happening is visible as an absence rather than as an eventual outage. 3. **Every name the entry point serves**, not just the primary one, since coverage is per name. ## Choosing between them Take the platform's certificate by default: automatic renewal removes the single most common self-inflicted outage in this area, and a key that cannot be exported cannot be leaked from a build server. Bring your own when something forces it — an issuer your organisation mandates, a certificate that must be identical on systems outside this platform, or a pinning arrangement with a partner. When you do, the cost is not the upload; it is owning the calendar, the alarm and the replacement drill for as long as the service exists.