Aktuelle Version vom 5. Oktober 2026, 07:34 Uhr

Server-Profile

Ein Server im REST-Modul ist ein eigenständiges TLS-Profil mit einer eigenen HTTP-Server-Instanz. In OBS können beliebig viele Server-Profile parallel betrieben werden, jedes mit eigenem Modus, eigenen Zertifikaten und eigenen Bindungen.

Typische Einsatzfälle für mehrere Profile:

Ein Public-Profil mit Standard-TLS auf Port 443 für externe Konsumenten.
Ein Internal-mTLS-Profil auf einem internen Port für Microservices, die zwingend ein Client-Zertifikat vorlegen müssen.
Ein Debug-Profil mit Plain-HTTP auf 127.0.0.1, ausschliesslich für lokale Tests.

Aufruf

Stammdaten -> Z Weitere Stammdaten -> REST-Server -> Server

Felder des Server-Profils

Feld	Beschreibung
Nr	Eindeutige Nummer 1-99, einmalig vergeben, kann später nicht mehr geändert werden
Name	Sprechender Name, eindeutig - erscheint in Protokoll, Statistik und Endpunkt-Zuordnung
Aktiv	Profil wird beim Start des REST-Dienstes geladen. Inaktive Profile starten nicht
zusätzliche Infos	Freitext zur Dokumentation (interner Kommentar, wird nicht ausgewertet)
kein SSL	Plain-HTTP-Modus, ausschliesslich für Debug. TLS-Felder werden ignoriert
mTLS-Modus aktiv	Mutual TLS: jeder Client muss ein gültiges Client-Zertifikat vorlegen
Zertifikat (cert)	PEM-Inhalt des Server-Zertifikats (inkl. ggf. Zwischen-CA-Kette)
Schlüssel (key)	PEM-Inhalt des privaten Schlüssels
Root-Zertifikat (ca)	PEM-Inhalt des CA-Zertifikats, gegen das '
Rate-Limit-Fenster	Länge des Rate-Limit-Fensters in Sekunden. Leer/0 = Standard 60
Erfolgsanfragen	Erlaubte erfolgreiche Anfragen je Schlüssel und Fenster. Leer/0 = Standard 120
Fehlanfragen	Erlaubte fehlgeschlagene Anfragen je Schlüssel und Fenster. Leer/0 = Standard 10
Anfragen	Erlaubte Anfragen des gesamten Profils je Fenster. Leer/0 = Standard 600
max. Verbindungen	Obergrenze gleichzeitiger Verbindungen (`rsv_max_conn`). Leer/0 = unbegrenzt. Sie deckt auch laufende Datei-Downloads ab, weil der Platz erst beim Trennen frei wird. Bei Überschreitung trennt der Server ohne HTTP-Antwort - der Wert gehört deutlich über den Normalbetrieb, als Reissleine
max. Anfragen	Obergrenze gleichzeitig verarbeiteter Anfragen (`rsv_max_parallel`). Leer/0 = unbegrenzt. Bei Überschreitung antwortet der Server 503 mit `Retry-After`, der Client darf es also gleich erneut versuchen
keine Kompression	Antworten dieses Profils werden nicht gepackt (`rsv_no_gzip`). Ohne Haken packt der Server JSON- und Textantworten ab 1024 Byte mit gzip, sofern der Client sie über `Accept-Encoding` annimmt. Der Haken betrifft nur die Antwortrichtung - komprimierte Anfragen nimmt der Server weiterhin entgegen

HINWEIS: max. Verbindungen und max. Anfragen sind die beiden

Lastgrenzen des Profils. Davon zu unterscheiden sind die festen Grenzen der persistenten Verbindungen - 10 Sekunden Leerlauf, 100 Anfragen je Verbindung -, die nicht der Last dienen, sondern der Hygiene und nicht einstellbar sind. Siehe REST-Server, Abschnitt Persistente

Verbindungen.

Die Inhalte der Zertifikate werden direkt in OBS als Text gespeichert. Zur Laufzeit schreibt der Server die PEM-Inhalte für den Bruchteil einer Sekunde in ein Temp-Verzeichnis, damit OpenSSL sie beim Start lesen kann; danach werden die Temp-Dateien sofort wieder gelöscht.

Modi

Modus	Voraussetzungen	Anwendung
Standard-TLS	Zertifikat + Schlüssel	Empfohlener Default für alle Server, die über das öffentliche Netz erreichbar sind
mTLS	Zertifikat + Schlüssel + Root-Zert.	Maschine-zu-Maschine-Kommunikation, in der jeder Client mit Cert validiert wird
Plain-HTTP	Haken kein SSL	Ausschliesslich lokale Tests. Erkennt TLS-Versuche auf dem Plain-Port und trennt sie direkt

Beide Richtungen werden erkannt: Eine unverschlüsselte Anfrage an einen TLS-Port (http statt https) beantwortet der Server mit HTTP 400 und einem Klartext-Hinweis. Die Abweisung erfolgt vor Authentifizierung, Rate-Limit und Endpunkt-Skript - ein falsch konfigurierter Client löst also keine Verarbeitung aus.

HINWEIS: Bei Standard-TLS und mTLS fährt der Server ohne Zertifikat und Schlüssel gar nicht erst hoch. Bei aktiver Erneuerung trägt der Dienst beides selbst ein. Plain-HTTP umgeht TLS komplett und ist nicht für Produktivumgebungen geeignet.

TLS-Version, Cipher und Zertifikats-Rotation

TLS-Version: Der Server erzwingt TLS 1.2. Die Cipher-Liste ist auf ECDHE-Schlüsselaustausch (Forward Secrecy) mit AEAD-Verfahren (AES-GCM, ChaCha20-Poly1305) beschränkt; CBC, statisches RSA-KEX und DHE sind ausgeschlossen.
HSTS: Jede Antwort eines TLS-Profils trägt Strict-Transport-Security: max-age=31536000; includeSubDomains. Ein Browser spricht die Adresse damit ein Jahr lang nur noch über HTTPS an. Beim Profil Kein SSL wird der Header bewusst nicht gesetzt - der Browser würde ihn sonst speichern und die Erzwingung auch auf produktive Sitzungen anwenden.
Rotation: Bei automatischer Erneuerung tauscht der Dienst das Zertifikat selbst und startet dabei nur das betroffene Server-Profil neu; die übrigen Profile und der Dienst laufen weiter. Bei manueller Pflege ändern Sie die PEM-Inhalte und starten den REST-Dienst neu - bis dahin läuft das alte Zertifikat weiter.
Certificate-Pinning: Mobile Clients können den Server-Public-Key pinnen. Zertifikatswechsel daher rechtzeitig ankündigen und mit einem Backup-Pin vorbereiten - der neue Pin muss vor dem Wechsel in einer Client-Version ausgerollt sein, sonst sperrt sich die App aus.

Automatische Zertifikatserneuerung

Der REST-Server kann sein TLS-Zertifikat selbst bei einer Zertifizierungsstelle beantragen und vor Ablauf erneuern. Zertifikat und privater Schlüssel entstehen dabei auf Ihrem Server und verlassen ihn nicht.

Voraussetzungen

Ein öffentlicher Name, der von aussen auf diesen Server zeigt.
Port 80 ist von aussen auf diesen Server weitergeleitet. Darüber prüft die Zertifizierungsstelle, dass Sie den Namen betreiben. Der Dienst öffnet den Port nur für die Dauer der Prüfung und schliesst ihn danach wieder.
Ausgehende HTTPS-Verbindungen zur Zertifizierungsstelle sind erlaubt.

HINWEIS: Port 80 wird unabhängig davon benötigt, auf welchem Port der REST-Server selbst lauscht. Die Prüfung der Zertifizierungsstelle beginnt immer auf Port 80.

Felder

Registerkarte 4 Zertifikaterneuerung:

Feld	Beschreibung
Automatische Erneuerung	deaktiviert = aus. Produktivbetrieb = der Dienst beantragt und erneuert das Zertifikat selbst. Testbetrieb = siehe Warnung unten
Zertifikatsname (FQDN)	Der Name, auf den das Zertifikat ausgestellt wird. Pflicht, sobald die Erneuerung aktiv ist
Kontakt bei der CA	Optional. Die Zertifizierungsstelle schickt an diese Adresse Warnungen, wenn ein Zertifikat abzulaufen droht
Zertifikat gültig bis	Ablaufdatum des aktiven Zertifikats
Testzertifikat aus Staging	Gesetzt, wenn das aktive Zertifikat aus dem Testbetrieb stammt
Zustand	idle = nichts zu tun, pending = Vorgang läuft, error = letzter Versuch fehlgeschlagen
Letzte Meldung	Ergebnis des letzten Vorgangs - im Störungsfall das erste Feld, in das Sie sehen
Gesperrt bis	Nach einem Fehlschlag wartet der Dienst bis zu diesem Zeitpunkt, bevor er es erneut versucht
Letzter Selbsttest am	Zeitpunkt der letzten Erreichbarkeitsprüfung
Selbsttest bestanden	Ergebnis der letzten Erreichbarkeitsprüfung

Die Felder ab Zertifikat gültig bis füllt der Dienst selbst; sie dienen der Anzeige.

Ablauf

Der Dienst sieht stündlich nach, ob etwas ansteht:

Selbsttest: Einmal wöchentlich prüft der Dienst über das Testsystem der Zertifizierungsstelle, ob Ihr Server von aussen erreichbar ist. Besteht der Test nicht, beantragt der Dienst kein Zertifikat.
Erneuerung: Ab 30 Tagen Restlaufzeit beantragt der Dienst ein neues Zertifikat.
Übernahme: Der Dienst prüft das neue Zertifikat, speichert es und bewahrt das bisherige als Rückfall auf. Anschliessend startet nur das betroffene Server-Profil neu.
Rückfall: Startet das Profil mit dem neuen Zertifikat nicht, aktiviert der Dienst wieder das vorherige.

Nach einem Fehlschlag wartet der Dienst zunehmend länger, bevor er es erneut versucht - eine, zwei, vier, acht und höchstens 24 Stunden. Das verhindert, dass ein dauerhafter Fehler das Anfragekontingent der Zertifizierungsstelle aufbraucht.

Befehle in der Konsole

Befehl	Wirkung
`cert`	Zeigt je Profil Betriebsart, Ablaufdatum, Zustand und das Ergebnis des letzten Selbsttests
`cert test`	Prüft sofort, ob der Server von aussen erreichbar ist. Beantragt kein Zertifikat
`cert renew`	Stösst die Erneuerung sofort an, auch wenn sie noch nicht fällig ist

Testbetrieb

ACHTUNG: Im Testbetrieb beantragt der Dienst das Zertifikat beim Testsystem der Zertifizierungsstelle. Einem solchen Zertifikat vertraut kein Client - Anwendungen können sich danach nicht mehr mit diesem Server verbinden. Verwenden Sie den Testbetrieb ausschliesslich auf Testsystemen. Zurück in den Produktivbetrieb kommen Sie, indem Sie das Feld Automatische Erneuerung auf Produktivbetrieb stellen; der Dienst holt daraufhin sofort ein gültiges Zertifikat, auch wenn das Testzertifikat noch lange läuft.

Rate-Limit je Profil

Jedes Server-Profil führt eigene Zähler und kann eigene Schwellen haben. Ein Profil, das gerade überrannt wird, bremst damit die anderen Profile nicht mit aus - das Public-Profil und das interne mTLS-Profil sind voneinander unabhängig.

Gezählt wird pro Schlüssel, und der Schlüssel ist der API-Key des Zugangs. Sendet ein Konsument keinen API-Key (Zugang mit *), wird ersatzweise auf die IP-Adresse gezählt.

HINWEIS: Das ist der wichtigste Punkt bei mobilen Anwendungen: Sitzen alle

Benutzer hinter einer gemeinsamen Firmen-IP und sendet die App keinen eigenen API-Key, teilen sich alle Benutzer einen Zähler. Mit den Standardwerten sind das 10 Fehlversuche für den ganzen Betrieb pro Minute - nach ein paar falschen Passworteingaben steht die Abteilung. Für solche Profile die Schwellen bewusst

höher setzen oder jedem Konsumenten einen eigenen API-Key geben.

Bleiben alle vier Felder leer (bzw. 0), gelten die Standardwerte. Die Werte werden beim Start des REST-Dienstes gelesen - eine Änderung wird erst nach einem Neustart wirksam.

Validierung beim Speichern

Immer geprüft wird:

Nr und Name sind vergeben, Nr liegt zwischen 1 und 99.
Nr und Name sind eindeutig.
Eingetragene Zertifikate und Schlüssel liegen im PEM-Format vor.
Ein eingetragener Zertifikatsname enthält keine Adresse, keinen Port und keine Leerzeichen.

Nur bei aktivem Profil zusätzlich:

Ohne kein SSL und ohne automatische Erneuerung sind Zertifikat und Schlüssel vorhanden.
Bei mTLS-Modus aktiv ist das Root-Zertifikat vorhanden.
Bei aktiver Erneuerung ist der Zertifikatsname vergeben, und kein SSL ist nicht gesetzt.

HINWEIS: Ein nicht aktives Profil dürfen Sie unvollständig speichern - es wird beim Start des Dienstes nicht geladen. Was Sie eintragen, wird trotzdem auf Plausibilität geprüft.

Bindungen

Eine Bindung ist die Kombination aus IP-Adresse und Port, auf der ein Server-Profil lauscht. Pro Server-Profil können mehrere Bindungen existieren, z.B. um die gleiche TLS-Konfiguration parallel auf 443 und 8443 anzubieten.

Aufruf

In der Server-Liste den gewünschten Server markieren und F6 drücken. Es öffnet sich die zum Server gehörende Bindungs-Liste.

Felder

Feld	Beschreibung
Host	IP-Adresse oder Hostname, auf dem gelauscht wird. 0.0.0.0 = alle IPv4-Adressen; 127.0.0.1 = nur lokal; explizite IPs binden gezielt auf eine Netzwerkkarte
Port	TCP-Port (1-65535). 443/8443 für HTTPS, frei wählbar für Debug-Profile
Aktiv	Bindung wird beim Server-Start geladen
Standard	Markiert die Standard-Bindung des Servers. Pro Server-Profil ist nur eine Standard-Bindung erlaubt

Wirksamkeit

Bindungen werden ausschliesslich beim Start des REST-Dienstes geladen. Änderungen werden daher erst nach einem Neustart aktiv. Bis dahin laufen die alten Bindungen weiter.

Listen-Funktionen

In der Server-Liste:

Einfg - neues Server-Profil
Return - vorhandenes Profil bearbeiten
F4 - Sortierung wählen
F6 - Bindungs-Liste des markierten Servers

@@ Zeile 26: / Zeile 26: @@
 | Aktiv               || Profil wird beim Start des REST-Dienstes geladen. Inaktive Profile starten nicht
 |-
-| Info                || Freitext zur Dokumentation (interner Kommentar, wird nicht ausgewertet)
+| zusätzliche Infos   || Freitext zur Dokumentation (interner Kommentar, wird nicht ausgewertet)
 |-
-| Kein SSL            || Plain-HTTP-Modus, ausschliesslich für Debug. TLS-Felder werden ignoriert
+| kein SSL            || Plain-HTTP-Modus, ausschliesslich für Debug. TLS-Felder werden ignoriert
 |-
-| mTLS                || Mutual TLS: jeder Client muss ein gültiges Client-Zertifikat vorlegen
+| mTLS-Modus aktiv    || Mutual TLS: jeder Client muss ein gültiges Client-Zertifikat vorlegen
 |-
-| Cert                || PEM-Inhalt des Server-Zertifikats (inkl. ggf. Zwischen-CA-Kette)
+| Zertifikat (cert)   || PEM-Inhalt des Server-Zertifikats (inkl. ggf. Zwischen-CA-Kette)
 |-
-| Key                 || PEM-Inhalt des privaten Schlüssels
+| Schlüssel (key)     || PEM-Inhalt des privaten Schlüssels
 |-
-| Root-Cert           || PEM-Inhalt des CA-Root-Zertifikats (Pflicht bei Standard-TLS, dort für Chain-Validierung, sowie bei mTLS, dort zusätzlich für Client-Cert-Verifikation)
+| Root-Zertifikat (ca) || PEM-Inhalt des CA-Zertifikats, gegen das '
+|-
+| Rate-Limit-Fenster  || Länge des Rate-Limit-Fensters in Sekunden. Leer/0 = Standard 60
+|-
+| Erfolgsanfragen     || Erlaubte erfolgreiche Anfragen je Schlüssel und Fenster. Leer/0 = Standard 120
+|-
+| Fehlanfragen        || Erlaubte fehlgeschlagene Anfragen je Schlüssel und Fenster. Leer/0 = Standard 10
+|-
+| Anfragen            || Erlaubte Anfragen des gesamten Profils je Fenster. Leer/0 = Standard 600
+|-
+| max. Verbindungen   || Obergrenze gleichzeitiger '''Verbindungen''' (<code>rsv_max_conn</code>). Leer/0 = unbegrenzt. Sie deckt auch laufende Datei-Downloads ab, weil der Platz erst beim Trennen frei wird. Bei Überschreitung trennt der Server '''ohne HTTP-Antwort''' - der Wert gehört deutlich über den Normalbetrieb, als Reissleine
+|-
+| max. Anfragen       || Obergrenze gleichzeitig '''verarbeiteter Anfragen''' (<code>rsv_max_parallel</code>). Leer/0 = unbegrenzt. Bei Überschreitung antwortet der Server '''503''' mit <code>Retry-After</code>, der Client darf es also gleich erneut versuchen
+|-
+| keine Kompression   || Antworten dieses Profils werden '''nicht''' gepackt (<code>rsv_no_gzip</code>). Ohne Haken packt der Server JSON- und Textantworten ab 1024 Byte mit gzip, sofern der Client sie über <code>Accept-Encoding</code> annimmt. Der Haken betrifft nur die Antwortrichtung - komprimierte '''Anfragen''' nimmt der Server weiterhin entgegen
 |}
+{{Hinweis|''max. Verbindungen'' und ''max. Anfragen'' sind die beiden
+'''Lastgrenzen''' des Profils. Davon zu unterscheiden sind die festen Grenzen der
+persistenten Verbindungen - 10 Sekunden Leerlauf, 100 Anfragen je Verbindung -,
+die nicht der Last dienen, sondern der Hygiene und nicht einstellbar sind. Siehe
+[[OBS/Kostenpflichtige Module/RESTServer|REST-Server]], Abschnitt Persistente
+Verbindungen.}}
 Die Inhalte der Zertifikate werden direkt in OBS als Text gespeichert. Zur Laufzeit schreibt der Server die PEM-Inhalte für den Bruchteil einer Sekunde in ein Temp-Verzeichnis, damit OpenSSL sie beim Start lesen kann; danach werden die Temp-Dateien sofort wieder gelöscht.
@@ Zeile 46: / Zeile 67: @@
 ! Modus               !! Voraussetzungen                       !! Anwendung
 |-
-| '''Standard-TLS'''  || Cert + Key + Root-Cert hinterlegt     || Empfohlener Default für alle Server, die über das öffentliche Netz erreichbar sind
+| '''Standard-TLS'''  || Zertifikat + Schlüssel                || Empfohlener Default für alle Server, die über das öffentliche Netz erreichbar sind
 |-
-| '''mTLS'''          || Cert + Key + Root-Cert (CA)           || Maschine-zu-Maschine-Kommunikation, in der jeder Client mit Cert validiert wird
+| '''mTLS'''          || Zertifikat + Schlüssel + Root-Zert.   || Maschine-zu-Maschine-Kommunikation, in der jeder Client mit Cert validiert wird
 |-
-| '''Plain-HTTP'''    || Haken ''Kein SSL''                    || Ausschliesslich lokale Tests. Erkennt TLS-Versuche auf dem Plain-Port und trennt sie direkt
+| '''Plain-HTTP'''    || Haken ''kein SSL''                    || Ausschliesslich lokale Tests. Erkennt TLS-Versuche auf dem Plain-Port und trennt sie direkt
 |}
-{{Hinweis|Bei Standard-TLS und mTLS fährt der Server ohne Cert/Key gar nicht erst hoch. Bei Standard-TLS ohne Root-Cert wird die Anlage abgelehnt - die Chain-Validierung benötigt das CA-Root. Plain-HTTP umgeht TLS komplett und ist nicht für Produktivumgebungen geeignet.}}
+Beide Richtungen werden erkannt: Eine '''unverschlüsselte Anfrage an einen
+TLS-Port''' (''http'' statt ''https'') beantwortet der Server mit '''HTTP 400'''
+und einem Klartext-Hinweis. Die Abweisung erfolgt '''vor''' Authentifizierung,
+Rate-Limit und Endpunkt-Skript - ein falsch konfigurierter Client löst also
+keine Verarbeitung aus.
+{{Hinweis|Bei Standard-TLS und mTLS fährt der Server ohne Zertifikat und Schlüssel gar nicht erst hoch. Bei aktiver Erneuerung trägt der Dienst beides selbst ein. Plain-HTTP umgeht TLS komplett und ist nicht für Produktivumgebungen geeignet.}}
 ==TLS-Version, Cipher und Zertifikats-Rotation==
-* '''TLS-Version:''' Der Server erzwingt '''TLS 1.2'''. Die Cipher-Liste ist auf ECDHE-SchlÜsselaustausch (Forward Secrecy) mit AEAD-Verfahren (AES-GCM, ChaCha20-Poly1305) beschrÄnkt; CBC, statisches RSA-KEX und DHE sind ausgeschlossen.
+* '''TLS-Version:''' Der Server erzwingt '''TLS 1.2'''. Die Cipher-Liste ist auf ECDHE-Schlüsselaustausch (Forward Secrecy) mit AEAD-Verfahren (AES-GCM, ChaCha20-Poly1305) beschränkt; CBC, statisches RSA-KEX und DHE sind ausgeschlossen.
-* '''Rotation:''' Ein Zertifikatswechsel erfolgt durch ändern der PEM-Inhalte in der DB und einen '''Neustart''' des REST-Dienstes (kein Hot-Reload). Bis zum Neustart lÄuft das alte Zertifikat weiter.
+* '''HSTS:''' Jede Antwort eines TLS-Profils trägt ''Strict-Transport-Security: max-age=31536000; includeSubDomains''. Ein Browser spricht die Adresse damit ein Jahr lang nur noch über HTTPS an. Beim Profil ''Kein SSL'' wird der Header bewusst '''nicht''' gesetzt - der Browser würde ihn sonst speichern und die Erzwingung auch auf produktive Sitzungen anwenden.
-* '''Certificate-Pinning:''' Mobile Clients kÖnnen den Server-Public-Key pinnen. Zertifikatswechsel daher '''rechtzeitig ankÜndigen''' und mit einem '''Backup-Pin''' vorbereiten - der neue Pin muss vor dem Wechsel in einer Client-Version ausgerollt sein, sonst sperrt sich die App aus.
+* '''Rotation:''' Bei '''automatischer Erneuerung''' tauscht der Dienst das Zertifikat selbst und startet dabei nur das betroffene Server-Profil neu; die übrigen Profile und der Dienst laufen weiter. Bei manueller Pflege ändern Sie die PEM-Inhalte und starten den REST-Dienst neu - bis dahin läuft das alte Zertifikat weiter.
+* '''Certificate-Pinning:''' Mobile Clients können den Server-Public-Key pinnen. Zertifikatswechsel daher '''rechtzeitig ankündigen''' und mit einem '''Backup-Pin''' vorbereiten - der neue Pin muss vor dem Wechsel in einer Client-Version ausgerollt sein, sonst sperrt sich die App aus.
+==Automatische Zertifikatserneuerung==
+Der REST-Server kann sein TLS-Zertifikat selbst bei einer Zertifizierungsstelle beantragen und vor Ablauf erneuern. Zertifikat und privater Schlüssel entstehen dabei auf Ihrem Server und verlassen ihn nicht.
+===Voraussetzungen===
+* Ein öffentlicher Name, der von aussen auf diesen Server zeigt.
+* '''Port 80''' ist von aussen auf diesen Server weitergeleitet. Darüber prüft die Zertifizierungsstelle, dass Sie den Namen betreiben. Der Dienst öffnet den Port nur für die Dauer der Prüfung und schliesst ihn danach wieder.
+* Ausgehende HTTPS-Verbindungen zur Zertifizierungsstelle sind erlaubt.
+{{Hinweis|Port 80 wird unabhängig davon benötigt, auf welchem Port der REST-Server selbst lauscht. Die Prüfung der Zertifizierungsstelle beginnt immer auf Port 80.}}
+===Felder===
+Registerkarte '''4 Zertifikaterneuerung''':
+{| class="wikitable"
+! Feld                       !! Beschreibung
+|-
+| Automatische Erneuerung    || ''deaktiviert'' = aus. ''Produktivbetrieb'' = der Dienst beantragt und erneuert das Zertifikat selbst. ''Testbetrieb'' = siehe Warnung unten
+|-
+| Zertifikatsname (FQDN)     || Der Name, auf den das Zertifikat ausgestellt wird. Pflicht, sobald die Erneuerung aktiv ist
+|-
+| Kontakt bei der CA         || Optional. Die Zertifizierungsstelle schickt an diese Adresse Warnungen, wenn ein Zertifikat abzulaufen droht
+|-
+| Zertifikat gültig bis      || Ablaufdatum des aktiven Zertifikats
+|-
+| Testzertifikat aus Staging || Gesetzt, wenn das aktive Zertifikat aus dem Testbetrieb stammt
+|-
+| Zustand                    || ''idle'' = nichts zu tun, ''pending'' = Vorgang läuft, ''error'' = letzter Versuch fehlgeschlagen
+|-
+| Letzte Meldung             || Ergebnis des letzten Vorgangs - im Störungsfall das erste Feld, in das Sie sehen
+|-
+| Gesperrt bis               || Nach einem Fehlschlag wartet der Dienst bis zu diesem Zeitpunkt, bevor er es erneut versucht
+|-
+| Letzter Selbsttest am      || Zeitpunkt der letzten Erreichbarkeitsprüfung
+|-
+| Selbsttest bestanden       || Ergebnis der letzten Erreichbarkeitsprüfung
+|}
+Die Felder ab ''Zertifikat gültig bis'' füllt der Dienst selbst; sie dienen der Anzeige.
+===Ablauf===
+Der Dienst sieht stündlich nach, ob etwas ansteht:
+# '''Selbsttest:''' Einmal wöchentlich prüft der Dienst über das Testsystem der Zertifizierungsstelle, ob Ihr Server von aussen erreichbar ist. Besteht der Test nicht, beantragt der Dienst kein Zertifikat.
+# '''Erneuerung:''' Ab 30 Tagen Restlaufzeit beantragt der Dienst ein neues Zertifikat.
+# '''Übernahme:''' Der Dienst prüft das neue Zertifikat, speichert es und bewahrt das bisherige als Rückfall auf. Anschliessend startet '''nur das betroffene Server-Profil''' neu.
+# '''Rückfall:''' Startet das Profil mit dem neuen Zertifikat nicht, aktiviert der Dienst wieder das vorherige.
+Nach einem Fehlschlag wartet der Dienst zunehmend länger, bevor er es erneut versucht - eine, zwei, vier, acht und höchstens 24 Stunden. Das verhindert, dass ein dauerhafter Fehler das Anfragekontingent der Zertifizierungsstelle aufbraucht.
+===Befehle in der Konsole===
+{| class="wikitable"
+! Befehl !! Wirkung
+|-
+| <code>cert</code> || Zeigt je Profil Betriebsart, Ablaufdatum, Zustand und das Ergebnis des letzten Selbsttests
+|-
+| <code>cert test</code> || Prüft sofort, ob der Server von aussen erreichbar ist. Beantragt kein Zertifikat
+|-
+| <code>cert renew</code> || Stösst die Erneuerung sofort an, auch wenn sie noch nicht fällig ist
+|}
+===Testbetrieb===
+{{Achtung|Im '''Testbetrieb''' beantragt der Dienst das Zertifikat beim Testsystem der Zertifizierungsstelle. Einem solchen Zertifikat vertraut '''kein''' Client - Anwendungen können sich danach nicht mehr mit diesem Server verbinden. Verwenden Sie den Testbetrieb ausschliesslich auf Testsystemen. Zurück in den Produktivbetrieb kommen Sie, indem Sie das Feld '''Automatische Erneuerung''' auf ''Produktivbetrieb'' stellen; der Dienst holt daraufhin sofort ein gültiges Zertifikat, auch wenn das Testzertifikat noch lange läuft.}}
+==Rate-Limit je Profil==
+Jedes Server-Profil führt '''eigene Zähler''' und kann '''eigene Schwellen''' haben.
+Ein Profil, das gerade überrannt wird, bremst damit die anderen Profile nicht mit
+aus - das Public-Profil und das interne mTLS-Profil sind voneinander unabhängig.
+Gezählt wird pro Schlüssel, und der Schlüssel ist der '''API-Key''' des Zugangs.
+Sendet ein Konsument keinen API-Key (Zugang mit ''*''), wird ersatzweise auf die
+'''IP-Adresse''' gezählt.
+{{Hinweis|Das ist der wichtigste Punkt bei mobilen Anwendungen: Sitzen alle
+Benutzer hinter einer gemeinsamen Firmen-IP und sendet die App keinen eigenen
+API-Key, teilen sich '''alle Benutzer einen Zähler'''. Mit den Standardwerten sind
+das 10 Fehlversuche für den ganzen Betrieb pro Minute - nach ein paar falschen
+Passworteingaben steht die Abteilung. Für solche Profile die Schwellen bewusst
+höher setzen oder jedem Konsumenten einen eigenen API-Key geben.}}
+Bleiben alle vier Felder leer (bzw. 0), gelten die Standardwerte. Die Werte werden
+'''beim Start''' des REST-Dienstes gelesen - eine Änderung wird erst nach einem
+Neustart wirksam.
 ==Validierung beim Speichern==
-Beim Speichern wird geprüft:
+Immer geprüft wird:
+* Nr und Name sind vergeben, Nr liegt zwischen 1 und 99.
+* Nr und Name sind eindeutig.
+* Eingetragene Zertifikate und Schlüssel liegen im PEM-Format vor.
+* Ein eingetragener Zertifikatsname enthält keine Adresse, keinen Port und keine Leerzeichen.
+Nur bei '''aktivem''' Profil zusätzlich:
+* Ohne ''kein SSL'' und ohne automatische Erneuerung sind Zertifikat und Schlüssel vorhanden.
+* Bei ''mTLS-Modus aktiv'' ist das Root-Zertifikat vorhanden.
+* Bei aktiver Erneuerung ist der Zertifikatsname vergeben, und ''kein SSL'' ist nicht gesetzt.
-* Nr und Name müssen vergeben sein.
+{{Hinweis|Ein '''nicht aktives''' Profil dürfen Sie unvollständig speichern - es wird beim Start des Dienstes nicht geladen. Was Sie eintragen, wird trotzdem auf Plausibilität geprüft.}}
-* Nr muss eindeutig sein.
-* Name muss eindeutig sein.
-* Bei nicht aktiviertem ''Kein SSL'' müssen Cert und Key vorhanden sein.
-* Bei nicht aktiviertem ''mTLS'' (= Standard-TLS) muss Root-Cert vorhanden sein.
 ==Bindungen==