Docs / Concepts de base / Domaines et SSL

Domaines et SSL

sh0 utilise Caddy comme proxy inverse, ce qui signifie que chaque domaine obtient automatiquement HTTPS via Let's Encrypt. Pas de gestion manuelle de certificats, pas de tâches cron, pas de fichiers de configuration -- ça fonctionne tout simplement.

Comment fonctionnent les domaines

Quand vous attribuez un domaine à une app, sh0 configure automatiquement Caddy pour :

  1. Écouter les requêtes entrantes sur ce domaine (ports 80 et 443).
  2. Obtenir et installer un certificat SSL de Let's Encrypt.
  3. Rediriger tout le trafic HTTP vers HTTPS.
  4. Proxyfier le trafic HTTPS vers le bon conteneur Docker.
  5. Renouveler automatiquement le certificat avant son expiration.
Flow diagram showing: Internet request to domain.com goes to Caddy (ports 80/443), which terminates SSL and proxies to the Docker container on its internal port
Caddy handles SSL termination and proxying

Ce processus entier est automatique. Une fois que vous ajoutez un domaine et pointez son DNS vers votre serveur, tout le reste est automatique.

Sous-domaines par défaut

Chaque app déployée sur sh0 Cloud reçoit un sous-domaine gratuit sous *.sh0.app. C'est utile pour :

  • Tests rapides sans configurer le DNS
  • Environnements de staging
  • Déploiements de prévisualisation pour les pull requests

Le sous-domaine est basé sur le nom de votre app : si votre app s'appelle my-api, elle sera accessible à my-api.sh0.app.

Note
Les sous-domaines par défaut sont entièrement fonctionnels avec SSL. Ils sont idéaux pour le développement et les tests. Pour la production, vous voudrez généralement utiliser votre propre domaine personnalisé.

Ajouter un domaine personnalisé

Pour ajouter un domaine personnalisé à votre app :

  1. Naviguez vers votre app et ouvrez l'onglet Domains.
  2. Cliquez sur Add Domain.
  3. Entrez votre nom de domaine (ex. : app.example.com ou example.com).
  4. Enregistrez et configurez votre DNS (voir ci-dessous).
Add Domain dialog showing a text input for the domain name, with examples of valid formats: 'example.com', 'app.example.com', 'api.example.com'
Adding a custom domain

Vous pouvez ajouter plusieurs domaines à une seule app. Tous serviront la même application. C'est utile pour :

  • Servir à la fois example.com et www.example.com
  • Supporter plusieurs noms de domaine pointant vers le même service
  • Garder le sous-domaine par défaut comme solution de repli à côté de votre domaine personnalisé

Configuration DNS

Pointez votre domaine vers votre serveur sh0 en ajoutant des enregistrements DNS chez votre registraire ou fournisseur DNS :

TypeNomValeurCas d'usage
A@IP de votre serveurDomaine racine (example.com)
AappIP de votre serveurSous-domaine (app.example.com)
CNAMEwwwexample.comRedirection www
Example DNS Records
# For app.example.com
Type: A
Name: app
Value: 203.0.113.50
TTL: 300

# For example.com (root domain)
Type: A
Name: @
Value: 203.0.113.50
TTL: 300
Propagation DNS
Les changements DNS se propagent généralement en quelques minutes mais peuvent prendre jusqu'à 24 heures. Vous pouvez vérifier que votre DNS est correctement configuré en utilisant dig app.example.com ou nslookup app.example.com.

SSL automatique

Les certificats SSL sont entièrement gérés par Caddy. Il n'y a rien à configurer, pas de certificats à téléverser et pas de scripts de renouvellement à maintenir.

Comment fonctionne Let's Encrypt

Quand vous ajoutez un domaine, ce qui suit se produit automatiquement :

  1. Challenge -- Caddy initie un challenge ACME HTTP-01 pour prouver la propriété du domaine.
  2. Émission -- Let's Encrypt vérifie le challenge et émet un certificat (généralement en quelques secondes).
  3. Installation -- Caddy installe le certificat et commence à servir le trafic HTTPS.
  4. Renouvellement -- Caddy renouvelle automatiquement le certificat 30 jours avant son expiration.
Le port 80 doit être ouvert
Le challenge HTTP-01 nécessite que le port 80 soit accessible depuis Internet. Si le port 80 est bloqué par un pare-feu, Caddy ne peut pas obtenir de certificats. Assurez-vous que ufw allow 80/tcp (ou équivalent) est configuré.
Domain list showing three domains with their SSL status: 'app.example.com' with a green lock icon and 'Valid until Dec 2026', 'api.example.com' with a green lock, and 'staging.example.com' with a yellow pending icon
SSL certificate status for each domain

Domaines wildcard

Les domaines wildcard (ex. : *.example.com) permettent à n'importe quel sous-domaine de router vers votre app. C'est utile pour :

  • Applications multi-locataires où chaque locataire obtient un sous-domaine
  • Déploiements de prévisualisation avec des sous-domaines uniques par branche
  • Routage géographique ou basé sur la langue
Le SSL wildcard nécessite un challenge DNS
Les certificats wildcard nécessitent un challenge DNS-01 au lieu de HTTP-01. Cela signifie que vous devez configurer une clé API de fournisseur DNS dans les paramètres sh0 pour que Caddy puisse créer des enregistrements TXT pour la vérification. Les fournisseurs supportés incluent Cloudflare, Route53, DigitalOcean et plus.
Configure DNS Provider for Wildcards
# In sh0 Settings > SSL, configure your DNS provider
# Example for Cloudflare:
DNS_PROVIDER=cloudflare
CLOUDFLARE_API_TOKEN=your-api-token

Statut du certificat SSL

La section Domaines de chaque app montre le statut SSL pour chaque domaine configuré :

StatutSignification
ActifLe certificat est valide et sert le trafic HTTPS.
En attentePas encore de certificat. Depuis la v1.6.25, l'émission se fait à la demande : le certificat est demandé à la première poignée de main TLS sur le domaine, donc un domaine reste En attente tant que personne ne s'y connecte. Survolez le badge pour lire pourquoi il attend encore.
En renouvellementLe certificat est en cours de renouvellement (30 jours avant l'expiration).
ÉchouéLe provisionnement du certificat a échoué. Vérifiez le DNS et les paramètres du pare-feu.

Deux règles de plus depuis la v1.6.25. Un domaine Actif dont le certificat disparaît du disque redevient En attente après deux vérifications consécutives, jamais sur une seule lecture. Et la date d'expiration du certificat est désormais lue dans le certificat lui-même : les alertes d'expiration ont enfin une valeur sur laquelle travailler.

Dépannage

Si votre domaine ne fonctionne pas ou si le certificat SSL ne se provisionne pas, vérifiez ces problèmes courants :

Le DNS ne pointe pas vers votre serveur

Exécutez dig +short your-domain.com et vérifiez qu'il retourne l'adresse IP de votre serveur. Sinon, mettez à jour vos enregistrements DNS et attendez la propagation.

Le port 80 est bloqué

Let's Encrypt a besoin du port 80 pour vérifier la propriété du domaine. Assurez-vous que votre pare-feu autorise le trafic TCP entrant sur le port 80. Vérifiez avec sudo ufw status.

Un autre service utilise le port 80/443

Si Nginx, Apache ou un autre serveur web tourne, il peut entrer en conflit avec Caddy. Arrêtez l'autre service : sudo systemctl stop nginx.

Limite de débit dépassée

Let's Encrypt a des limites de débit (50 certificats par domaine par semaine). Si vous atteignez la limite, attendez ou utilisez l'environnement de staging pour les tests. Les logs Caddy indiqueront les erreurs de limite de débit.

Debugging Commands
# Check if DNS resolves correctly
dig +short app.example.com

# Test if port 80 is accessible from outside
curl -I http://app.example.com

# Check Caddy logs for certificate errors
journalctl -u sh0 | grep -i "certificate\|tls\|acme"
Previous
Apps & Services
Next
Environment Variables