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?
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.
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
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
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.
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?
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.
ich sitz auch an dem selben Problem, nur mit eigenen Zertifikaten (Interne CA)
Die Einstellungen werden nicht übernommen, egal was ich setz ob let’s encrypt oder Eigene Zertifikate.
journalctl -u certmanater sagt mir hier “keine Einträge”
Gibt es noch andere Stellen, an denen ich hier Logs finde?
Steve war schneller