OBS/Kostenpflichtige Module/RESTServer/Server-Profile: Unterschied zwischen den Versionen
Zur Navigation springen
Zur Suche springen
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
| Zeile 55: | Zeile 55: | ||
{{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.}} | {{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.}} | ||
==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. | |||
* '''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. | |||
* '''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. | |||
==Validierung beim Speichern== | ==Validierung beim Speichern== | ||
Aktuelle Version vom 29. Juni 2026, 11:07 Uhr
Internet-Shop
Der modified ECommerce Shop
Shop-Menü
- A Preise aktualisieren
- C Personen übertragen
- E Kategorien verwalten
- G Kataloge verwalten
- I Merkliste übertragen
- K Varianten übertragen
- L Artikelvarianten übertragen
- M Referenzarten übertragen
- N Lagerbestände verwalten
- U Bestellungen einlesen
- V leere Passworte füllen
- W Update-Informationen zurücksetzen
- X Konfiguration
- Z Protokoll
Automatische Vorgänge
Preislisten
ZUGFeRD
Factoring
UPS
IMS Professional
SMS
Mehrlager-Verwaltung
Mehrsprachen Modul
Multilanguage Modul
Einfache Produktionsnachverfolgung
DMS - Dokumenten Management System
DMS Dokumente
Tasten und Schaltflächen
F10 Weit.
QR Zeiterfassung
EVA Marketing Tool
Technikersteuerung
Termin-Projekte
Edifact-Schnittstelle
Backup Überwachung Email
Anlagenbuchhaltung
OBS Geo Daten
DeliSprint / DPD
Filialen
Auto-Waagen
Cashback
Moebelschnittstelle
Tourenplanung
Dokumenten Manager
DocuWare-Schnittstelle
OFML-Kalkulation
Pascom
Versicherungsschaden
Gutschriftsanzeigen
OCPP Ladestationen
Kameraverwaltung
DataInOut
REST-Schnittstelle
Sammelverträge
Craftboxx
OpenMasterData / IDS
Sammelpositionen
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 |
| Info | Freitext zur Dokumentation (interner Kommentar, wird nicht ausgewertet) |
| 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 |
| Cert | PEM-Inhalt des Server-Zertifikats (inkl. ggf. Zwischen-CA-Kette) |
| 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) |
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 | Cert + Key + Root-Cert hinterlegt | 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 |
| 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.
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.
- 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.
- 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.
Validierung beim Speichern
Beim Speichern wird geprüft:
- Nr und Name müssen vergeben sein.
- 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
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