Pascom 18 Let's encrypt ohne Funktion

german

#1

Meine Pascom-Onsite Installation zieht sich kein Let’s encrypt Zertifikat sondern behält immer das selbst signierte Zertifikat.

Nutze eine feste IP im RZ, habe natürlich einen FQDN und auch die entsprechenden Firewall-Regeln, denn ein Zugriff von extern sowohl über http: als auch https: ist möglich, halt nur mit dem self signed.

Habe auch schon die Einstellungen zurück gesetzt auf lokale IP, Interface neu gestartet und dann wieder von vorne begonnen. Es ändert nichts.

Jemand ne Idee dazu? Und vor allem, wie bzw. wo kann ich sehen, dass er überhaupt versucht, ein Zertifikat von let’s encrypt zu holen und zu installieren bzw. wo kann ich die installierten Zertifikate sehen?

Gruß
Michael


#2

Gibt’s hierfür schon eine Lösung? Habe grad beim Kunden das gleiche Problem…


#3

Bei mir lag es an fehlerhaften DSN-Einträgen. Es wurde mehr als eine IP-Adresse zurückgeliefert (1&1) für den DNS-A-Eintrag


#4

ein A-Eintrag. Zeigt auf die richtige IP. Firewall reicht alles an die Pascom durch ( 80/443 ) - und auch den ganzen anderen Spaß… tut auch an sich alles - nur halt kein Zertifikat.


#5

Hi,

schau dir bitte mal die Logs im Interfacecontainer an, ggf sieht man dort das Problem:
journalctl -u certmanager

Grüße,
Steve


#6

Hallo,

was sagt denn der CerManager wenn Du den direkt ausführst?
:slight_smile: Steve war schneller

Vermute das du es zu oft versucht hast.


#7

Managing certificate [voip.xxx.de]
Manage lets encrypt certifcate
Requesting certificate for [voip.xxx.de]
20181206122651 [ERROR] acme.storageops: could not obtain authorization for voip.xxx.de: failed all combinations
20181206122651 [ERROR] acme.storageops: Target(voip.xxx.de;https://acme-v01.api.letsencrypt.org/directory;0): failed to request certificate: failed all combinations
20181206122651 [ERROR] acme.storageops: error while processing targets: the following errors occurred:
error satisfying Target(voip.xxx.de;https://acme-v01.api.letsencrypt.org/directory;0): failed all combinations
20181206122651 [ERROR] acme.storageops: failed to reconcile: the following errors occurred:
error satisfying Target(voip.xxx.de;https://acme-v01.api.letsencrypt.org/directory;0): failed all combinations
20181206122651 [CRITICAL] acmetool: fatal: reconcile: the following errors occurred:
error satisfying Target(voip.xxx.de;https://acme-v01.api.letsencrypt.org/directory;0): failed all combinations
Falling back to self signed because something is wrong with lets encrypt
Manage self signed certificate
Checking previously created certificate
/etc/ssl/certs/cs-tls-cert.pem: OK
Certificate seems to be ok
/etc/ssl/certs/cs-tls-cert.pem: OK
Certificate seems to be ok
Certificate was not changed`

Die IP löst sauber auf. Aber der stupser in den interface container hat mich auf jeden fall schon mal weiter gebracht… so langsam versteh ich die cloudstack magie :wink:

PS: Die Domain ist nicht xxx.de :wink:


#8

Dachte ich mir schon, die ist mit sicherheit heiß begehrt…
Mir sagt der Fehler leider noch nichts, aber nur um andere Probleme ausschließen (auch wenn das hier glaube ich schon alles geklärt wurde):
-Das Interface hat als FQDN voip.xxx.de eingetragen.
-voip.xxx.de besitzt nur einen A Record, die IP hier wird auf dem Router der diese inne hat auf die IP des o.g. Interfaces via 80 und 443 gefordwarded.
-es gibt keinen anderen Host/Interface, der versucht via let’s encrypt ein Zertifkat für voip.xxx.de auszustellen.
-der pascom 18 Host selbst löst voip.xxx.de auch auf die öffentliche IP auf

Ist das alles so richtig/gegeben?

Grüße,
Steve


#9

Hallo zusammen,

Blockquote
-der pascom 18 Host selbst löst voip.xxx.de auch auf die öffentliche IP auf

Für was ist denn das nötig? Würde ein /etc/hosts eintrag reichen?

Habe auch das Problem. Selbst wenn ich ein eigenes Zertifikat einspiele (hab ein Wildcard Zertifikat) behält der Server das selbst signierte!

Gruß moJ0


#10

Hi @moJ090,

ich bin mir nicht sicher ob das wirklich für let’s encrypt notwendig ist, aber beim Start des Interface Containers löst der Host den FQDN auf und paramtetriert damit den Kamailio (Session Border Controller). Das kann man sich ein wenig wie SIP ALG vorstellen, der SBC setzt in den SIP Headern dann diese IP beispielsweise als Ziel für die RTP Streams. Mobile Clients hätten dann daruch z.B. kein Audio.
Deswegen ist es ratsam für interne Geräte immer ein eigenes Interface zu verwenden, wenn diese nicht über die Firewall laufen sollen.

Grüße,
Steve


#11

Hi @Steve,

also für andere Webserver etc. habe ich das noch nie benötigt. Hab meistens mit Split-DNS gerabeitet und da konnten sich die Hosts selbst nur mit der internen IP auflösen.

also verstehe ich es richtig, dass ich zwei Interfaces für interne und externe Verbindungen einrichten sollte?
Beispiel:

Interface1: 192.168.132.1 voip-int.domain.de
Interface2: 192.168.132.2 voip-ext.domain.de wird aber auf die externe IP aufgelöst und auf die interne .2 genattet

so ungefähr?

Macht doch dann aber wieder Probleme wenn ich mit meinem Notebook unterwegs bin und dann immer den Hostnamen ändern muss und wenn ich mit meinem Mobilfunkgerät im internen Netz bin oder?

Könnt ihr das Problem mit dem eigenen Zertifikat reproduzieren?

Gruß moJO


#12

Hi,

ich selbst bin mit der let’s encrypt Implementierung nicht so vertraut, aber dort wo ich die Einrichtung begleitet habe hat es immer funktioniert.
Das “Externe Geräte im internen Netz” Problem sollte sich ja nur stellen, wenn das WLAN im gleichen Segment wie das Interface ist, ansonsten sollte ja das Portforwarding regulär greifen und die Antwort wieder über diesen Router gehen und somit “Rückübersetzt” werden. Wenn Client und Interface im gleichen Netz sind, benötigt man ein Hairpin NAT bzw zusätzliches SourceNAT, damit die pascom dem Client nicht direkt antworten kann und somit alles korrekt “rückübersetzt” wird.

Grüße,
Steve