# HyperTwist VPS TLS certificate and IONOS separation guide

Created on `2026-05-30`.

## Purpose

This document records how TLS currently works on the new VPS, how it was
recreated during the migration, how to reason about paid IONOS SSL products
versus VPS-side Certbot, and what future operators need to know before changing
certificate assignments in IONOS.

## Scope boundary

This guide is about the browser-facing TLS certificates presented by NGINX on
the VPS at `212.227.13.220`.

It is **not** a billing ledger and it is **not** the authoritative source for
IONOS renewal dates. Billing dates must still be checked in IONOS before any
contract cancellation.

## Core rule

For the current live deployment, the certificate that matters is the one NGINX
actually presents from the VPS.

Operational consequence:

- if DNS points a hostname at `212.227.13.220`
- and NGINX on that VPS presents a valid certificate for that hostname
- then browsers, payment providers, and API clients evaluate **that** VPS-side
  certificate chain
- they do **not** care whether an IONOS UI assignment exists for the same
  hostname

## Current live VPS certificate inventory

As of `2026-05-30`, the new VPS serves the following Certbot-managed
certificates:

- `scriptoriumai.io`
  - `scriptoriumai.io`
  - `www.scriptoriumai.io`
- `app.scriptoriumai.io`
  - `app.scriptoriumai.io`
  - `api.scriptoriumai.io`
- `git.scriptoriumai.io`
  - `git.scriptoriumai.io`
  - `ci.scriptoriumai.io`
- `verticaltension.com`
  - `verticaltension.com`
  - `app.verticaltension.com`
  - `www.verticaltension.com`
- `api.verticaltension.com`
  - `api.verticaltension.com`
- `hypertwist.app`
  - `hypertwist.app`
  - `www.hypertwist.app`
- `vectorshell.com`
  - `vectorshell.com`
  - `www.vectorshell.com`
- `git.verticaltension.com`
  - `git.verticaltension.com`
  - `ci.verticaltension.com`

Certbot renewals are handled by:

- `certbot.timer`

## How the current VPS-side TLS was implemented

The live pattern was:

1. move DNS for the intended hostname to `212.227.13.220`
2. ensure NGINX has a vhost for that hostname
3. run Certbot with the NGINX installer
4. let Certbot write the certificate references into the matching vhost
5. validate externally with HTTPS requests

Representative commands used during the migration:

```bash
sudo certbot --nginx --non-interactive --agree-tos \
  --cert-name verticaltension.com --expand \
  -d verticaltension.com -d www.verticaltension.com -d app.verticaltension.com

sudo certbot --nginx --non-interactive --agree-tos \
  --cert-name hypertwist.app \
  -d hypertwist.app -d www.hypertwist.app

sudo certbot --nginx --non-interactive --agree-tos \
  --cert-name vectorshell.com \
  -d vectorshell.com -d www.vectorshell.com

sudo certbot --nginx --non-interactive --agree-tos \
  --cert-name git.verticaltension.com \
  -d git.verticaltension.com -d ci.verticaltension.com
```

Validation commands used after issuance:

```bash
sudo certbot certificates
sudo nginx -t
curl -I https://scriptoriumai.io
curl -I https://www.verticaltension.com
curl -I https://hypertwist.app
curl -I https://vectorshell.com
```

## What "server-side certificate" means here

"Server-side certificate" in this migration means:

- the private key and full chain live on the VPS
- NGINX reads those files from `/etc/letsencrypt/live/...`
- the browser's TLS handshake is completed directly against the VPS

That is enough for a legitimate HTTPS deployment.

## Are Certbot / Let's Encrypt certificates legitimate?

Yes.

They are legitimate public TLS certificates signed by a browser-trusted public
certificate authority.

Important nuance:

- a Let's Encrypt certificate is not the same commercial product as a paid
  IONOS SSL subscription
- but it **is** a valid browser-trusted certificate for HTTPS when issued for
  the correct hostname and served correctly

## Payment-provider and browser trust posture

The current VPS-side Certbot certificates are appropriate for normal public
HTTPS use, including user-facing websites and payment-related browser flows,
provided the hostname and chain are correct.

Relevant trust facts:

- Stripe validates certificates against trusted roots, hostname match, and
  validity windows
- Stripe publishes trust for modern public CA chains including Let's Encrypt
  roots
- Paddle's hosted checkout and checkout-domain guidance requires working HTTPS
  and valid domains, not a specific paid certificate vendor

Operational conclusion:

- the current Certbot certificates are legitimate for user-facing HTTPS
- they are not second-class certificates
- they do not need to be "upgraded" to an IONOS-paid certificate just to be
  acceptable to browsers, Stripe, or Paddle

## IONOS SSL products versus VPS-side Certbot

These are different certificate-management models.

IONOS paid SSL product:

- separate commercial product
- managed through IONOS product UI
- can be downloaded and manually installed on an "own server" path

VPS-side Certbot / Let's Encrypt:

- certificate issuance and renewal happen from the VPS
- no IONOS UI assignment is needed for the live TLS handshake
- current deployment already uses this model successfully

## Safe reasoning about IONOS "unassign" versus "cancel"

These are not the same operation.

Unassign in IONOS:

- changes the IONOS-side product assignment state
- does **not** change the NGINX certificate files already live on the VPS
- does **not** by itself break the current VPS-side HTTPS deployment for a
  hostname that is already served correctly from Certbot on the VPS

Cancel in IONOS:

- billing / subscription action
- effective cancellation timing depends on IONOS product terms and renewal date
- must be checked in IONOS before actually canceling

Practical rule:

- unassigning the paid IONOS certificate from a hostname that is already served
  correctly by the VPS-side Certbot configuration should be operationally safe
- cancellation timing should still be chosen with billing awareness, not by
  guesswork

## What future operators should do before touching IONOS certificate products

1. confirm the hostname already resolves to `212.227.13.220`
2. confirm `curl -I https://hostname` works externally
3. confirm `sudo certbot certificates` lists the hostname on the VPS
4. confirm `sudo nginx -t` is clean
5. only then consider unassigning the matching IONOS certificate product
6. check IONOS billing dates before any final cancellation

## Recreation checklist for a brand-new hostname

If a new hostname must be added later:

1. create or update the NGINX vhost
2. point DNS to `212.227.13.220`
3. wait for propagation
4. run Certbot with the matching `-d` names
5. test HTTPS externally
6. record the new certificate name and domain coverage

## External references

IONOS:

- management of SSL certificates in the control panel:
  `https://www.ionos.com/help/ssl-certificates/administration-of-user-managed-ssl-certificates/management-of-ssl-certificates-in-the-control-panel/`
- own-server setup:
  `https://www.ionos.com/help/ssl-certificates/setting-up-user-managed-ssl-certificates/setting-up-a-user-managed-ssl-certificate-ssl-starter-/-ssl-starter-wildcard/`
- manual certificate download / install:
  `https://www.ionos.com/help/ssl-certificates/administration-of-user-managed-ssl-certificates/downloading-ssl-certificate-files-for-manual-installation/`
- cancellation flow:
  `https://www.ionos.com/help/my-account/cancellation/cancelling-ssl-certificates/`

Stripe:

- TLS certificate requirements:
  `https://docs.stripe.com/tls-certificates`

Paddle:

- Paddle.js checkout open:
  `https://developer.paddle.com/paddle-js/methods/paddle-checkout-open/`
- checkout transaction / approved-domain guidance:
  `https://developer.paddle.com/build/transactions/pass-transaction-checkout/`

Let's Encrypt:

- certificate chains and roots:
  `https://letsencrypt.org/certificates/?lang=en`
- certificate compatibility:
  `https://letsencrypt.org/docs/certificate-compatibility/`

## Related companion docs

- `C:\HyperTwist\docs\ops\HYPERTWIST_VPS_POST_CUTOVER_OPERATIONAL_INVARIANTS_2026-05-30.md`
- `C:\HyperTwist\docs\ops\HYPERTWIST_PLATFORM_TAXONOMY_ALIAS_AND_RENAME_PLAN_2026-05-30.md`
