Beheer van SSL-certificaten voor meerdere 3CX-systemen

Het uitrollen van meerdere 3CX MCU’s en AI-transcriptie engines binnen één LAN

Wanneer je meerdere services draait die gebruikmaken van publieke FQDN’s en SSL-certificaten, kan het beheer hiervan al snel complex worden.

Om duidelijk te maken wat wel en niet mogelijk is, starten we met een veelvoorkomende setup en laten we vervolgens zien hoe variaties invloed hebben op je SSL-certificaatstrategie.

De standaard voorbeeldopstelling

Voor de uitleg gaan we uit van een omgeving met drie systemen binnen hetzelfde lokale netwerk:

• 3CX PhoneSystem – IP-adres: 192.168.0.10
• 3CX On-Board MCU – IP-adres: 192.168.0.20
• 3CX On-Board AI – IP-adres: 192.168.0.30

3CX FQDN’s (standaard)

Een standaard 3CX-installatie maakt gebruik van een eigen ACME-client om automatisch Let’s Encrypt-certificaten aan te maken en te vernieuwen. Hierbij wordt het certificaat direct gekoppeld aan de 3CX-installatie en de bijbehorende FQDN. Er zijn drie belangrijke vereisten:

1. Dedicated publieke IP-adressen

Voor deze setup heeft elke machine een eigen publiek IP-adres nodig. Bijvoorbeeld:

2. Split DNS

Je interne DNS-server moet zo worden ingericht dat:

• Binnen het LAN verwijzen FQDN’s naar de interne IP-adressen
• Buiten het LAN verwijzen dezelfde FQDN’s naar de publieke IP-adressen

De eenvoudigste manier is om A- (of AAAA-) records aan te maken op je lokale DNS-server:

• FQDN: mypbx.3cx.com.cy – 3CX PhoneSystem – 192.168.0.10
• FQDN: mymcu.my3cx.net – 3CX On-Board MCU – 192.168.0.20
• FQDN: myai.my3cx.net – 3CX On-Board AI –  192.168.0.30

Deze aanpak staat ook bekend onder verschillende namen, zoals:

• Pinpoint DNS Zones
• Response Policy Zones (RPZ)
• Split-Horizpn DNS or Views
• Shadow Zones

3. Port forwarding voor automatische certificaatvernieuwing

Je firewall of router moet verkeer correct doorsturen naar:

• mymcu.my3cx.net → 20.20.20.21:80 → 192.168.0.20:80
• myai.my3cx.net → 20.20.20.22:80 → 192.168.0.30:80

Zo kan Let’s Encrypt de systemen bereiken voor certificaatupdates.

Het 3CX PhoneSystem (mypbx.3cx.com.cy) heeft dit niet nodig, omdat dit via de 3CX cloudinfrastructuur wordt geregeld.

Let op: Heb je niet voor elke machine een eigen publiek IP-adres beschikbaar? Dan moet je werken met eigen (custom) FQDN’s.

Custom FQDN’s met Let’s Encrypt (DNS-automatisering)

Deze aanpak is geschikt wanneer alle 3CX-systemen binnen het LAN draaien en niet direct vanaf internet bereikbaar zijn. Dit vereist een handmatige setup buiten de standaard 3CX configuratie. Voor dit voorbeeld gebruiken we:

• mypbx.example.com
• mymcu.example.com
• myai.example.com

Ook hier gelden enkele vereisten:

1. Automatiseringsscript

Je hebt een script nodig op een machine op het LAN dat:

• Gebruikmaakt van de Let’s Encrypt DNS-01 challenge
• Periodiek draait om certificaten tijdig te vernieuwen
• Communiceert met Let’s Encrypt voor aanvraag/vernieuwing
• Via de DNS-provider API verificatierecords aanmaakt
• De gedownloade certificaatbestanden opslaat, bijvoorbeeld:

2. Script voor certificaatupdates

Daarnaast heb je een script nodig dat:

• Controleert of er nieuwe certificaten zijn
• Deze naar de juiste locatie kopieert
• Oude bestanden verwijdert om dubbele acties te voorkomen

Voorbeeldscript voor mymcu.example.com die je kunt opslaan in “/root/certupdate.sh” (hetzelfde kan worden gedaan voor myai.example.com“):

Geef het script de juiste rechten:

…en voeg het toe aan je crontab, bijvoorbeeld dagelijks om 03:00.

Custom FQDN – handmatige certificaatvernieuwing

Wanneer automatisering niet mogelijk is (bijvoorbeeld omdat je DNS-provider geen API ondersteunt of je met wildcard-certificaten werkt), blijft het proces grotendeels hetzelfde.

Het verschil is dat je de stappen handmatig uitvoert in plaats van geautomatiseerd.

Alternatieve Certificate Authority

Gebruik je een andere Certificate Authority dan Let’s Encrypt?
Dan is er een algemene handleiding beschikbaar met advies over het kiezen van de juiste CA voor jouw situatie.