f9fe0e3419
**Motivations:** - Partie connectée du skeleton accessible seulement si pairing satisfait + relais OK, avec page type skeleton (avatar, notifications). - Éviter « Aucun service disponible » : contrat présent en dur dans la page, transmis à l’iframe ; navigation évidente ou automatique vers login. - Sécuriser postMessage (origine UserWallet uniquement) ; déployer data sur le proxy et certificat data.certificator.4nkweb.com. - Vulgariser cryptographie (ECDH, AES-GCM, Schnorr, workflow, collecte signatures) ; documenter correctifs et architecture. **Root causes:** - Section connectée affichée sans vérifier pairing/relay ; possibilité de forger pairing-relay-status depuis la console. - Iframe masquée ou /login chargé avant réception du contrat → graphe vide, redirection vers /services. - Pas de contrôle d’origine sur les messages reçus ; pas de projet website-data ni config Nginx/certificat pour data. **Correctifs:** - Vérification msg.origin === USERWALLET_ORIGIN dans handleMessage (skeleton). - Si session mais pas pairingRelayStatus : afficher iframe pour réception du statut, message « Vérification du statut… ». - Contrat envoyé dès load iframe (init iframe.src = USERWALLET_ORIGIN) ; au clic « Se connecter », envoi contract + navigate-login (service, membre). - UserWallet : écoute navigate-login → navigation /login?service=&membre= ; LoginScreen avec service+membre en URL ne redirige plus vers /services, dispatch E_SELECT_SERVICE / E_SELECT_MEMBER. **Evolutions:** - Message pairing-relay-status (iframe → parent) ; canShowConnectedSection exige login + pairing OK + relay OK ; page connectée avec header avatar + icône notifications. - Skeleton : getLoginContext, sendNavigateLoginToIframe, onIframeLoad, loginRequested/iframeLoaded ; contrat envoyé avec serviceUuid, membreUuid. - UserWallet : PairingRelayStatusMessage, envoi depuis HomeScreen/LoginScreen ; type navigate-login, handleNavigateLogin dans useChannel. - Page cryptographie.html (workflow, algorithmes, collecte signatures) ; liens nav, build. - website-data (Vite, channel, config), start/service/install ; configure-nginx-proxy + Certbot pour data.certificator.4nkweb.com. - fixKnowledge (postmessage-origin, section-connectee-non-affichee) ; features (partie-connectee-pairing-relay, userwallet-iframe-key-isolation). **Pages affectées:** - website-skeleton (index, main, config, serviceContract, cryptographie, technique, membre, contrat, vite.config, README). - userwallet (HomeScreen, LoginScreen, useChannel, iframeChannel, relay, crypto, iframe, Pairing*, RelaySettings, WordInputGrid, syncUpdateGraph, specs/synthese). - website-data (nouveau), configure-nginx-proxy, docs DOMAINS_AND_PORTS README, features, fixKnowledge, userwallet features/docs.
8.5 KiB
8.5 KiB
Domaines et Ports - Infrastructure Certificator
Auteur : Équipe 4NK Date : 2026-01-24 Version : 1.0
Vue d'Ensemble
Ce document liste tous les domaines, ports et services de l'infrastructure Certificator Bitcoin Signet.
Domaines et Services
Domaines Principaux
| Domaine | Service | Port Local | Description |
|---|---|---|---|
anchorage.certificator.4nkweb.com |
API d'Ancrage | 3010 | API REST pour ancrer des documents (machine bitcoin 192.168.1.105) |
certificator.4nkweb.com |
API LeCoffre Anchor | 3004 | API REST LeCoffre pour ancrer (machine prod 192.168.1.103) |
watermark.certificator.4nkweb.com |
API Filigrane | 3022 | API REST pour ajouter des filigranes et ancrer |
antivir.certificator.4nkweb.com |
API ClamAV | 3023 | API REST pour scanner les fichiers (antivirus) |
dashboard.certificator.4nkweb.com |
Dashboard | 3020 | Interface web de supervision |
faucet.certificator.4nkweb.com |
API Faucet | 3021 | API REST pour distribuer des sats |
mempool.4nkweb.com |
Mempool | 3015 | Explorateur de blockchain Bitcoin |
skeleton.certificator.4nkweb.com |
Website skeleton | 3024 | Site squelette iframe UserWallet |
data.certificator.4nkweb.com |
Website data | 3025 | Iframe data (non clés), site ↔ data ↔ userwallet |
Configuration Nginx
Tous les domaines sont routés via le proxy Nginx sur le serveur 192.168.1.100 (proxy).
Configuration du proxy :
- Point d'entrée unique :
4nk.myftp.biz(DynDNS) - Routage HTTPS vers les services backend appropriés
- Certificats SSL/TLS : Let's Encrypt (renouvellement automatique)
Ports Fixes
Ports des APIs (Fixés dans les services systemd)
| Port | Service | API | Fichier de Service |
|---|---|---|---|
| 3010 | API d'Ancrage | api-anchorage |
api-anchorage/anchorage-api.service |
| 3020 | Dashboard | signet-dashboard |
signet-dashboard/signet-dashboard.service |
| 3021 | API Faucet | api-faucet |
api-faucet/faucet-api.service |
| 3022 | API Filigrane | api-filigrane |
api-filigrane/filigrane-api.service |
| 3023 | API ClamAV | api-clamav |
api-clamav/clamav-api.service |
| 3024 | Website skeleton | website-skeleton |
website-skeleton/website-skeleton.service |
| 3025 | Website data | website-data |
(à définir, ex. website-data/website-data.service) |
Important : Les ports 3010, 3020, 3021, 3022, 3023, 3024 sont fixes et définis dans les fichiers de service systemd. Ils ne peuvent pas être modifiés sans modifier les services.
Ports Bitcoin Core
| Port | Protocole | Service | Description |
|---|---|---|---|
| 38332 | TCP | RPC | Interface JSON-RPC pour contrôler le nœud |
| 38333 | TCP/UDP | P2P | Réseau peer-to-peer Bitcoin Signet |
| 28332 | TCP | ZMQ | Publication des blocs bruts |
| 28333 | TCP | ZMQ | Publication des transactions brutes |
| 28334 | TCP | ZMQ | Publication des hash de blocs |
Ports Mempool
| Port | Protocole | Service | Description |
|---|---|---|---|
| 3015 | HTTP/HTTPS | Web | Interface web Mempool (exposé via nginx) |
| 8999 | HTTP | API | Mempool Backend API (interne) |
Services Systemd
Tous les services sont configurés avec systemd pour un redémarrage automatique.
Liste des Services
# Vérifier le statut de tous les services
sudo systemctl status anchorage-api
sudo systemctl status signet-dashboard
sudo systemctl status faucet-api
sudo systemctl status filigrane-api
sudo systemctl status clamav-api
sudo systemctl status website-skeleton
Commandes de Gestion
# Démarrer un service
sudo systemctl start <service-name>
# Arrêter un service
sudo systemctl stop <service-name>
# Redémarrer un service
sudo systemctl restart <service-name>
# Voir les logs
sudo journalctl -u <service-name> -f
# Activer au démarrage
sudo systemctl enable <service-name>
# Désactiver au démarrage
sudo systemctl disable <service-name>
Architecture Réseau
Internet
│
├─→ 4nk.myftp.biz (DynDNS)
│ └─→ 192.168.1.100 (proxy) - Point d'entrée unique
│ │
│ ├─→ anchorage.certificator.4nkweb.com → 192.168.1.105:3010 (API Anchorage Bitcoin)
│ ├─→ certificator.4nkweb.com → 192.168.1.103:3004 (API LeCoffre Anchor)
│ ├─→ watermark.certificator.4nkweb.com → 192.168.1.103:3022 (API Filigrane)
│ ├─→ antivir.certificator.4nkweb.com → 192.168.1.103:3023 (API ClamAV)
│ ├─→ dashboard.certificator.4nkweb.com → 192.168.1.103:3020 (Dashboard)
│ ├─→ skeleton.certificator.4nkweb.com → 192.168.1.105:3024 (Website skeleton)
│ ├─→ faucet.certificator.4nkweb.com → 192.168.1.103:3021 (API Faucet)
│ └─→ mempool.4nkweb.com → 192.168.1.104:3015 (Mempool)
Vérification des Ports
Vérifier qu'un port est en écoute
# Vérifier un port spécifique
sudo ss -tlnp | grep :3010
# Vérifier tous les ports des APIs
sudo ss -tlnp | grep -E ':(3010|3020|3021|3022|3023|3024)'
Tester la connectivité
# Tester depuis le serveur
curl http://localhost:3010/health
curl -s http://localhost:3020/api/blockchain/info | head -c 200 # Dashboard : pas de /health
curl http://localhost:3021/health
curl http://localhost:3022/health
curl http://localhost:3023/health
# Tester depuis l'extérieur (via domaine)
curl https://anchorage.certificator.4nkweb.com/health
curl https://certificator.4nkweb.com/health
curl -s https://dashboard.certificator.4nkweb.com/api/blockchain/info | head -c 200
Certificats SSL/TLS
Tous les domaines utilisent des certificats Let's Encrypt gérés automatiquement par Certbot.
Vérifier les certificats
# Sur le serveur proxy (192.168.1.100)
sudo certbot certificates
# Vérifier un certificat spécifique
openssl s_client -connect certificator.4nkweb.com:443 -servername certificator.4nkweb.com
Renouvellement
Le renouvellement est automatique via Certbot. Pour forcer un renouvellement :
sudo certbot renew
DNS
Tous les domaines utilisent des enregistrements CNAME pointant vers 4nk.myftp.biz (DynDNS).
Exemple de configuration DNS (Gandi) :
anchorage.certificator.4nkweb.com. 3600 IN CNAME 4nk.myftp.biz.
certificator.4nkweb.com. 3600 IN CNAME 4nk.myftp.biz.
watermark.certificator.4nkweb.com. 3600 IN CNAME 4nk.myftp.biz.
antivir.certificator.4nkweb.com. 3600 IN CNAME 4nk.myftp.biz.
dashboard.certificator.4nkweb.com. 3600 IN CNAME 4nk.myftp.biz.
faucet.certificator.4nkweb.com. 3600 IN CNAME 4nk.myftp.biz.
APIs d'Ancrage
Il existe deux APIs d'ancrage distinctes :
1. API d'Ancrage Bitcoin (anchorage.certificator.4nkweb.com)
- Domaine :
anchorage.certificator.4nkweb.com - Machine : 192.168.1.105 (bitcoin)
- Port : 3010
- Service systemd :
anchorage-api - Répertoire :
/home/ncantu/Bureau/code/bitcoin/api-anchorage - Bitcoin RPC : 127.0.0.1:38332 (Bitcoin Core dans Docker sur la même machine)
- Description : API principale pour ancrer des documents sur Bitcoin Signet
2. API LeCoffre Anchor (certificator.4nkweb.com)
- Domaine :
certificator.4nkweb.com - Machine : 192.168.1.103 (prod)
- Port : 3004
- Service : Processus Node.js dans
/srv/4NK/certificator.4nkweb.com/lecoffre-anchor-api - Bitcoin RPC : localhost:18443 (Bitcoin Core sur machine distante)
- Description : API LeCoffre pour ancrer des documents (service séparé)
Important : Pour l'API d'ancrage Bitcoin principale, utiliser anchorage.certificator.4nkweb.com qui pointe vers la machine bitcoin (192.168.1.105).
Notes Importantes
-
Ports fixes : Tous les ports des APIs sont fixes et définis dans les services systemd. Ne pas modifier sans mettre à jour les services.
-
Redémarrage automatique : Tous les services sont configurés avec
Restart=alwayspour un redémarrage automatique en cas d'échec. -
Sécurité : Les services utilisent
NoNewPrivileges=trueetPrivateTmp=truepour une meilleure sécurité. -
Logs : Tous les logs sont envoyés vers
journaldet peuvent être consultés avecjournalctl. -
Environnement : Les variables d'environnement (ports, hosts) sont définies dans les fichiers de service systemd.