Sur cette page

Installer le Webserver-Front (DMZ)

Le Webserver-Front est une replique en lecture seule du Webserver (ADMIN) concue pour etre exposee en DMZ. Il est alimente exclusivement par un push unidirectionnel mutuellement authentifie (mTLS) depuis ADMIN : le Front n’ouvre jamais de connexion vers ADMIN ni vers aucun composant interne. Cette page couvre le deploiement complet : generation de la PKI, organisation du dossier pki/, configuration du fichier de chaque cote (webserver.json sur ADMIN, webserver_front.json sur FRONT) et verification du flux de replication.

Dans cette page, ADMIN designe le Webserver normal (licencie, interne) et FRONT la replique compilee avec le tag front. Pour l’architecture et le modele de confiance, voir Webserver-Front (replique DMZ) ; pour l’exploitation au quotidien, voir Exploiter le Webserver-Front.

Rappel securite

  • ADMIN → FRONT uniquement. ADMIN pousse des deltas incrementaux en continu et un instantane complet toutes les FrontReconcileMins minutes vers le recepteur de replication du FRONT (mTLS, sur le PortAPI du FRONT).
  • Trois protections independantes enveloppent chaque push : authentification mTLS par certificat client, jeton RS256 revocable de courte duree (paire de cles de replication dediee), et chiffrement AES-256-GCM de la charge utile avec la cle partagee ReplKey.
  • Les secrets ne quittent jamais ADMIN. Seule une liste blanche de buckets est repliquee, et les champs sensibles (jetons, mots de passe, IP/ports/endpoints internes) sont supprimes avant de quitter ADMIN.
  • Aucune licence necessaire sur le FRONT. C’est une replique de l’ADMIN licencie ; il fonctionne sans fichier license_MNS.dat.

Etape 1 — Generer la PKI

Generez tout le materiel cryptographique sur une machine sure (idealement l’hote ADMIN ou un poste hors ligne), puis distribuez uniquement les fichiers necessaires a chaque cote.

1.1 CA de replication et certificats



# CA racine - conserver la cle CA hors ligne apres emission

openssl genrsa -out repl_ca.key 4096
openssl req -x509 -new -nodes -key repl_ca.key -sha256 -days 3650 -subj "/CN=mugnsoft-repl-ca" -out repl_ca.crt

# Certificat client ADMIN (presente par ADMIN lors des POST vers le Front)

openssl genrsa -out admin_client.key 4096
openssl req -new -key admin_client.key -subj "/CN=webserver-admin" -out admin_client.csr
printf "extendedKeyUsage=clientAuth\n" > admin_ext.cnf
openssl x509 -req -in admin_client.csr -CA repl_ca.crt -CAkey repl_ca.key -CAcreateserial \
 -out admin_client.crt -days 825 -sha256 -extfile admin_ext.cnf

# Certificat serveur FRONT : signe par la MEME CA.
# La liste des SAN doit couvrir TOUS les noms qu'ADMIN composera dans FrontEndpoint :
# une entree DNS: par nom d'hote et une entree IP: par adresse IP.

openssl genrsa -out front_server.key 4096
openssl req -new -key front_server.key -subj "/CN=front.example.com" -out front_server.csr
cat > front_ext.cnf <<EOF
subjectAltName=DNS:front.example.com,IP:203.0.113.10
extendedKeyUsage=serverAuth
EOF
openssl x509 -req -in front_server.csr -CA repl_ca.crt -CAkey repl_ca.key -CAcreateserial \
 -out front_server.crt -days 825 -sha256 -extfile front_ext.cnf

# verifier les SAN avant deploiement
openssl x509 -in front_server.crt -noout -ext subjectAltName

Les SAN doivent correspondre a FrontEndpoint

Le client TLS de Go effectue une verification stricte des SAN. Si le FrontEndpoint d’ADMIN pointe vers une adresse IP (ex. 203.0.113.10:8050), le certificat doit contenir une entree SAN IP: correspondante — un certificat avec uniquement des SAN DNS echoue avec x509: cannot validate certificate for <IP> because it doesn't contain any IP SANs. Si FrontEndpoint utilise un nom d’hote, ce nom exact doit figurer en SAN DNS: (le CN seul ne suffit pas). En cas de doute, incluez les deux.

Note :

Sous Git Bash pour Windows, prefixez la valeur de -subj par un double slash (-subj "//CN=...") pour eviter la reecriture de chemin MSYS.

1.2 Cle partagee de chiffrement de la charge utile

La ReplKey est une chaine hexadecimale de 64 caracteres (32 octets = AES-256). La meme valeur doit etre configuree sur ADMIN et sur le Front.


openssl rand -hex 32

# exemple de sortie : 3addba52d5bb500caad74d211d8832f595b08842e846ae1db2aa080538a4d326

1.3 Paire de cles de signature des jetons de replication

Cette paire de cles RSA signe les jetons de courte duree qui authentifient chaque push. Elle est volontairement distincte de la paire de cles JWT de connexion utilisateur (config/sec/) : le Front ne detient que la moitie publique, donc un Front compromis ne peut forger ni des push de replication ni des sessions utilisateur ADMIN.


openssl genrsa -out repl_sign.key 2048
openssl rsa -in repl_sign.key -pubout -out repl_sign.pub

1.4 Distribuer les fichiers

Creez un dossier pki/ a cote de chaque executable et copiez uniquement les fichiers listes ci-dessous. La cle privee de la CA (repl_ca.key) reste hors ligne.

Fichier pki/ ADMIN pki/ FRONT Role
repl_ca.crt oui oui CA utilisee par chaque cote pour verifier le certificat de l’autre
admin_client.crt oui non Certificat client mTLS d’ADMIN
admin_client.key oui non Cle client mTLS d’ADMIN
repl_sign.key oui non Cle privee RSA signant les jetons de replication
repl_sign.pub non oui Cle publique RSA verifiant les jetons de replication
repl_ca.key non non Cle de la CA - a conserver hors ligne

Le certificat serveur du Front ne va pas dans pki/ ; il va a l’emplacement TLS standard du repertoire d’installation du Front :



# sur l'hote FRONT

cp front_server.crt <repertoire-install-front>/config/ssl/certificates/webserver.pem
cp front_server.key <repertoire-install-front>/config/ssl/private/webserver.key

Etape 2 — Deployer le Front

Copiez le paquet webserver-front sur l’hote DMZ. Arborescence attendue :


webserver-front/
webserver_front.exe # build front du webserver (webserver_front sous Linux)
webserver_front.json # configuration service + replication (voir ci-dessous)
web-front/ # assets de l'interface web, servis depuis le disque (non embarques)
pki/
repl_ca.crt
repl_sign.pub
config/
ssl/
certificates/webserver.pem # front_server.crt
private/webserver.key # front_server.key

Note :

Aucun license_MNS.dat n’est requis sur le Front. Les autres dossiers (dbs/, data/, log/, …) sont crees automatiquement au premier demarrage.

webserver_front.json du Front

Le fichier de configuration porte le nom de l’executable (<nom-executable>.json) : webserver_front.exe lit webserver_front.json.


{
"HTTPS": "true",
"PortAPI": "8050",
"PortWEB": "9090",
"RunUser": "",

"ReplKey": "3addba52d5bb500caad74d211d8832f595b08842e846ae1db2aa080538a4d326",
"ReplCACert": "pki/repl_ca.crt",
"ReplPubKey": "pki/repl_sign.pub"
}
Champ Lu par Description
PortAPI FRONT Port du recepteur de replication mTLS — le seul endpoint vers lequel ADMIN pousse. Doit correspondre au port du FrontEndpoint d’ADMIN
PortWEB FRONT Port de l’interface web en lecture seule exposee aux utilisateurs finaux
ReplKey les deux Cle AES-256 partagee (64 caracteres hexa) dechiffrant chaque charge utile de replication. Doit etre identique sur ADMIN et FRONT
ReplCACert les deux Certificat de la CA. Le Front l’utilise pour exiger et verifier le certificat client d’ADMIN au niveau TLS
ReplPubKey FRONT Moitie publique de la paire de cles de signature ; verifie le jeton RS256 porte par chaque push

Installer et demarrer le service



# Windows (invite de commandes en administrateur)

webserver_front.exe install && webserver_front.exe start

# Linux

./webserver_front install && ./webserver_front start

Etape 3 — Configurer ADMIN

Ajoutez les champs de replication et Front au webserver.json d’ADMIN, puis redemarrez le service ADMIN. ADMIN a besoin exactement des fichiers marques “pki/ ADMIN” dans le tableau de l’etape 1.4 — en particulier il n’a pas besoin de repl_sign.pub (ReplPubKey est un champ FRONT uniquement) :


{
"HTTPS": "true",
"PortAPI": "8050",
"PortWEB": "9090",
"RunUser": "",

"ReplKey": "3addba52d5bb500caad74d211d8832f595b08842e846ae1db2aa080538a4d326",
"ReplCACert": "pki/repl_ca.crt",
"ReplClientCert": "pki/admin_client.crt",
"ReplClientKey": "pki/admin_client.key",
"ReplSignKey": "pki/repl_sign.key",

"FrontEnabled": "true",
"FrontEndpoint": "front.example.com:8050",
"FrontReconcileMins": "5",
"FrontGracePeriodMins": "0"
}

Reference des champs de replication

Champs PKI / cryptographiques (Repl*)

Ces champs sont provisionnes hors bande dans webserver.json sur les deux hotes. Ils ne transitent jamais par le canal de replication et ne sont jamais modifiables depuis l’interface Settings.

Champ Cote Description
ReplKey ADMIN + FRONT Cle AES-256 partagee en hexa (64 caracteres, a generer avec openssl rand -hex 32). Chaque lot de replication est chiffre AES-GCM avec cette cle : les donnees restent confidentielles et inviolables de bout en bout — meme si TLS est termine par un reverse proxy intermediaire. La valeur doit etre identique des deux cotes
ReplCACert ADMIN + FRONT Chemin du certificat CA verifiant le pair. Sur le FRONT il valide le certificat client d’ADMIN (RequireAndVerifyClientCert : un pair sans certificat client signe par la CA n’atteint jamais le handler). Sur ADMIN il valide le certificat serveur du Front
ReplClientCert ADMIN Chemin du certificat client TLS presente par ADMIN lors des POST vers le Front
ReplClientKey ADMIN Chemin de la cle privee de ReplClientCert
ReplSignKey ADMIN Chemin de la cle privee RSA (PEM) signant le jeton RS256 de courte duree attache a chaque push /replicate. Paire dediee, distincte des cles JWT de connexion utilisateur
ReplPubKey FRONT Chemin de la cle publique RSA (PEM) verifiant ces jetons. Le Front ne detient que cette moitie publique : un Front compromis ne peut forger ni push de replication ni sessions utilisateur ADMIN

Champs operationnels du Front (Front*)

Ces champs resident sur ADMIN et pilotent le push. Ils peuvent etre definis dans webserver.json ou surcharges a chaud depuis la page Settings d’ADMIN.

Champ Defaut Description
FrontEnabled "false" Mettre a "true" pour activer la pompe de replication sur ADMIN
FrontEndpoint — hote:port du recepteur de replication mTLS du Front. Le port est le PortAPI du Front (ex. front.example.com:8050)
FrontReconcileMins "5" Cadence en minutes du push d'instantane complet (les deltas incrementaux circulent en continu entre deux). La valeur est estampillee sur chaque push, et le Front signale son flux comme perime — avec un bandeau dans l’interface — si aucun push valide n’arrive dans 3x cet intervalle
FrontGracePeriodMins "0" (off) Delai de grace en minutes avant qu’un statut applicatif non-OK devienne visible sur le Front. Quand une application quitte l’etat OK pour un etat degrade, les utilisateurs externes du Front continuent de voir le dernier statut sain pendant cette fenetre — les equipes d’exploitation resolvent souvent les incidents courts avant que les utilisateurs exterieurs ne les remarquent. Les vues temps reel d’ADMIN, l’historique de statut, le SLA et l’alerting ne sont pas affectes. Les DOWNTIME planifies sont propages immediatement

Etape 4 — Verifier

Depuis l’hote ADMIN, testez le canal mTLS avec le certificat client :


curl --cacert pki/repl_ca.crt --cert pki/admin_client.crt --key pki/admin_client.key \
 https://front.example.com:8050/uptime

# reponse attendue : ok

Puis controlez :

  • Journal ADMIN (log/webserver.log) : la pompe rapporte les lots pousses ; les erreurs de certificat ou de cle apparaissent ici.
  • Journal FRONT : replicateHandler - applied N/N items (snapshot=true) en niveau debug ; les rejets de jeton ou de charge utile sont journalises en warning.
  • Interface FRONT : ouvrez https://front.example.com:9090/ — moniteurs, applications et donnees de decouverte apparaissent apres la premiere reconciliation (jusqu’a FrontReconcileMins minutes). Un bandeau rouge indique un flux perime.

Depannage :

  • token rejected sur le FRONT : le ReplPubKey du Front ne correspond pas au ReplSignKey d’ADMIN, ou les horloges divergent trop.
  • payload rejected sur le FRONT : la ReplKey differe entre les deux hotes.
  • Erreurs de handshake TLS : certificat non signe par ReplCACert, ou le nom d’hote de FrontEndpoint ne correspond pas au SAN du certificat serveur du Front.
  • x509: cannot validate certificate for <IP> because it doesn't contain any IP SANs : FrontEndpoint joint le Front par adresse IP mais le certificat serveur ne porte que des SAN DNS:. Reemettez-le avec une entree IP: correspondante (voir etape 1.1), ou basculez FrontEndpoint vers un nom d’hote present dans les SAN DNS: du certificat.
  • apply failed ... cannot find the path specified : le dossier dbs/ du Front est absent — corrige automatiquement au premier demarrage sur les builds recents ; sur les builds plus anciens, creez le dossier dbs/ manuellement.

Voir aussi

Traductions

Structure des dossiers