Certificates and VPN

This page covers two networking pages in the admin panel:

• SSL Queue — every HTTPS certificate on the platform, and the requests users make to delete or reissue one
• VPN Interfaces — extra private networks that chosen teams can put their labs on

SSL Queue

Admin Panel → Platform → SSL Queue (/admin/ssl), headed "SSL Manager".

Certificates are issued automatically when a user publishes a domain; nothing here is needed for that. This page is for the exceptions: a certificate that is stuck, expired, orphaned, or that a user has asked to be removed or reissued from their own HTTPS page. See HTTPS for the user's side.

How a request flows

Nothing is deleted until someone selects Apply Approved.

Tabs

Tab	What it is for
All Certificates	Every certificate. Search by domain, alternative name or owner; filter by status (valid, expiring soon, expired, renewal failing), by issuer, or Orphaned only.
Residue Cleanup	Expired certificates that still carry stale domains. Queue all sends them all for deletion (with confirmation).
Pending Review	Users' requests, with their reason and verification state. Tick rows, then Approve Selected or Reject Selected (with confirmation).
Approved	Deletions waiting to be applied, and the Apply Approved button
History	Past requests and who reviewed them

Badges in All Certificates mark extra names on a certificate, protected and orphaned certificates, a pending deletion, and the last error. Details shows the full certificate.

Queue Deletion on any certificate sends it straight to Approved, skipping review, because you are the reviewer. The confirmation warns that deleting a valid certificate forces it to be reissued.

Applying approved deletions

1. Open the Approved tab and check the list.
2. Select Apply Approved.
3. Read the confirmation and confirm.

Every lab loses HTTPS for a few seconds

Applying deletions restarts the platform's web proxy once. For a few seconds every lab and service on the platform is unreachable over HTTPS. A backup is taken first. Apply in a quiet period, and batch deletions so you apply once rather than several times.

While a batch runs, a banner shows and the button is disabled. When it finishes, a result banner shows how many were applied and skipped, the backup taken and how long the interruption lasted.

The requesting user is not notified when you approve or reject. Tell them if they are waiting on you.

Limits and refusals

The queue protects the platform from too many proxy restarts and from certificate-authority rate limits. Expect these messages:

Message	Why
"maximum 6 apply batches per hour"	Each admin may select Apply Approved at most 6 times an hour
"An apply batch is already in progress"	Only one batch runs at a time across the whole platform. Wait for the banner to clear. A batch can take several minutes.
"No approved requests to apply"	The Approved tab is empty
"maximum 20 admin deletion requests per day"	Each admin may queue at most 20 deletions a day with Queue Deletion
"Certificate covers a protected platform domain"	Certificates for the platform's own domains cannot be deleted from here
"A deletion request for this certificate is already open"	Someone has already queued it; find it in Pending Review or Approved
"Request no longer eligible"	When you approve, the platform checks the request again. If the certificate has recovered or its domain no longer points here, the request is closed as stale instead.
"Request was already decided by another admin"	Another admin acted first. Reload the page.

Requests you did not make

Some rows in Approved and History show "system" as the reviewer. After a lab is redeployed, the platform checks for certificates left behind for names that no lab uses anymore, and queues them for deletion as already approved. They wait for Apply Approved like any other deletion.

SSL Queue decisions are not written to the audit log. The History tab shows who reviewed each request and when.

Shown on labs.selfmade.ninja, the Selfmade Ninja Academy platform. On your own platform you will see your own domain and data.

VPN Interfaces

Admin Panel → Platform → VPN Interfaces (/admin/vpn)

Every user's devices connect to the platform's default VPN network. This page lets you add extra WireGuard networks and give them to chosen teams, so the people building labs in those teams can put their labs on a separate network. How users connect devices is covered in Devices.

Creating an interface

Creating an interface only makes a record. Nothing changes on the VPN server until you provision it.

1. Fill in Display name and, optionally, the interface name (leave blank to pick the next free one).
2. Choose the Node.
3. Enter the address range. It must not overlap any existing range.
4. Enter a Listen port. It must be free and different from the default network's port.
5. Enter the endpoint host and port that devices will connect to.
6. Select Create record.

Managing interfaces

The table shows each interface's name, address range, port, endpoint, node, status, peers and teams. Refresh reloads it. The default network is read-only.

Action	What it does	Confirmation
Provision	Brings the interface live on the VPN server, without a restart	Yes
Teams	Chooses which teams may use it	—
Edit	Changes Display name, endpoint, node and Available. The address range, port and keys are fixed once provisioned.	—
Deprovision	Takes the interface down and deletes its address pool. The record stays. Refused while any device still uses it.	Yes
Delete	Removes the record and revokes every team's access. Only possible once deprovisioned and unused. Cannot be undone.	Yes

If the platform's VPN provisioning is not set up yet, records still save and you can provision them later.

VPN interface actions are not recorded in the audit log.

Next

• Access control — who has access to which interface
• Labs and instances
• Platform settings