0 Persons are tagged with #letsencrypt

#letsencrypt

rainerhgw@diasp.org
Rainer Sokoll ✅

Vor ein paar Wochen stolperte ich über mod_md - geil! Kein certbot, kein dehydrated - Apache macht alles selber.
POC:

MDContactEmail webmaster@sokoll.com
MDCertificateAgreement accepted
MDomain ionos-1.sokoll.com
<VirtualHost 74.208.189.173:80>
ServerName ionos-1.sokoll.com
ServerAdmin webmaster@sokoll.com
RedirectMatch permanent ^/(.*) https://ionos-1.sokoll.com/$1
ErrorLog ${APACHE_LOG_DIR}/ionos-1.sokoll.com-error.log
CustomLog ${APACHE_LOG_DIR}/ionos-1.sokoll.com-access.log combined
</VirtualHost>
<VirtualHost 74.208.189.173:443>
ServerName ionos-1.sokoll.com
DocumentRoot /var/www/html
Protocols h2 http/1.1 acme-tls/1
SSLEngine on
ErrorLog ${APACHE_LOG_DIR}/ionos-1.sokoll.com-error.log
CustomLog ${APACHE_LOG_DIR}/ionos-1.sokoll.com-access.log combined
</VirtualHost>

Das ist alles!

Sehrsehr geil

#Apache #Letsencrypt #ACME

3 Likes
6 Comments
rainerhgw@diasp.org
Rainer Sokoll ✅

Das ist dann wohl dumm gelaufen?
```
+ ERROR: An error occurred while sending post-request to https://acme-staging-v02.api.letsencrypt.org/acme/order/5901893/9737591784 (Status 500)

Details:
HTTP/2 500
server: nginx
date: Thu, 13 Jul 2023 15:46:07 GMT
content-type: application/problem+json
content-length: 132
cache-control: public, max-age=0, no-cache
link: https://acme-staging-v02.api.letsencrypt.org/directory;rel="index"
replay-nonce: 88B8RcwVs0IwiIPbe0IYQv-29KfskgUB7ZVGsw4W5ywgCwQ

{
"type": "urn:ietf:params:acme:error:serverInternal",
"detail": "Failed to retrieve order for ID 9737591784",
"status": 500
}

EXPECTED value GOT EOF
```

#letsencrypt

bkoehn@diaspora.koehn.com
Brad Koehn ☑️

Alright, after a bit more puttering about I've got my #k3s #Kubernetes cluster networking working. Details follow.

From an inbound perspective, all the nodes in the cluster are completely unavailable from the internet, firewalled off using #hetzner's firewalls. This provides some reassurance that they're tougher to hack, and makes it harder for me to mess up the configuration. All the nodes are on a private network that allows them to communicate with one another, and that's their exclusive form of communication. All the nodes are allowed any outbound traffic. The servers are labeled in Hetzner's console to automatically apply firewall rules.

In front of the cluster is a Hetzner firewall that is configured to forward public internet traffic to the nodes on the private network (meaning the load balancer has public IPv4 and IPv6 addresses, and a private IPv4 address that it uses to communicate with the worker nodes). The load balancer does liveness checks on each node and can prevent non responsive nodes from receiving requests. The load balancer uses the PROXY protocol to preserve source #IP information. The same Hetzner server labels are used to add worker nodes to the load balancer automatically.

The traffic is forwarded to an #nginx Daemonset which k3s keeps running on every node in the cluster (for high availability), and the pods of that DaemonSet keep themselves in sync using a ConfigMap that allows tweaks to the nginx configuration to be applied automatically. Nginx listens on the node's private IP ports and handles #TLS termination for #HTTP traffic and works with Cert-Manager to maintain TLS certificates for websites using #LetsEncrypt for signing. TLS termination for #IMAP and #SMTP are handled by #Dovecot and #Postfix, respectively. Nginx forwards (mostly) cleartext to the appropriate service to handle the request using Kubernetes Ingress resources to bind ports, hosts, paths, etc. to the correct workloads.

The cluster uses #Canal as a #CNI to handle pod-to-pod networking. Canal is a hybrid of Calico and Flannel that is both easy to set up (basically a single YAML) and powerful to use, allowing me to set network policies to only permit pods to communicate with the other pods that they need, effectively acting as an internal firewall in case a pod is compromised. All pod communication is managed using standard Kubernetes Services, which behind the scenes simply create #IPCHAINS to move traffic to the correct pod.

The configuration of all this was a fair amount of effort, owing to Kubernetes' inherent flexibility in the kinds of environments it supports. But by integrating it with the capabilities that Hetzner provides I can fairly easily create an environment for running workloads that's redundant and highly secure. I had to turn off several k3s "features" to get it to work, disabling #Traefik, #Flannel, some strange load balancing capabilities, and forcing k3s to use only the private network rather than a public one. Still, it's been easier to work with than a full-blown Kubernetes installation, and uses considerably fewer server resources.

Next up: storage! Postgres, Objects, and filesystems.

2 Likes
katzenjens@pod.tchncs.de
Jens [defunct

Server aufsetzen wie vor 20 Jahren...

tl;dr Selbstbeweihräucherung durch händischen Webserveraufbau ;) Nerd-Monolog

Nachdem ich mich die letzten Wochen kurz mit Docker beschäftigt habe, bin ich zu dem Entschluß gekommen, für mich ist das erstmal nix. Andererseits war es jetzt auch mal wieder Zeit, meinen Server im RZ auf eine neue Distribution hochzuhieven.

Bisher war es so: Vor 20 Jahren habe ich angefangen, einen eigenen Server zu betreiben, da Hoster mich bei meinem Betrieb mit Forum und Chat schnell rausgeworfen hatten. Die ersten Server kosteten für wenig Leistung recht viel. Und so habe ich dann Mitfahrer... ähm, Kunden... ähm, Patienten aufgenommen. Und weil ich nicht alles selbst machen wollte, habe ich dann SysCP (heute Froxlor) installiert. Das Gesamtpaket, damals sogar mit Mail. SSL und andere Verschlüsselung war da noch nicht bis kaum existent. Trotzdem lief es alles sauber. Nur ein einziges Mal hatte ich mir eine PHP Shell eingetreten durch ein kaputtes CMS.

Die ganzen Jahre habe ich das so durchgezogen, Froxlor rüstete auch immer weiter auf. War mir zu dem Zeitpunkt noch egal, es lief ja soweit alles. Nur irgendwann wurde Spam überhand und meine Mails wurden auch nicht mehr überall angenommen, obwohl alles richtig konfiguriert war.

Das war dann der Punkt, es ist so 12 Jahre her, wo ich meine Kundschaft dann an Google verwiesen habe, und im DNS den MX nach dorthin verbogen habe. Alles lief prima. Wobei die restlichen Patienten inzwischen auch keinen Bock mehr hatten, die Seiten zu bearbeiten. Da fast alles statisch war, habe ich den Kram dann übernommen. Bis auf einen Patienten war das auch easy.

So, und nun kam ja die Tage die Hiobsbotschaft seitens Google, die wollen für Konto mit eigener Domain nun Geld sehen. Da kam natürlich die Frage auf, ob ich mich nach langer Zeit mal wieder an einen Mailserver drantraue. Nach einigem Googlen hatte ich dann große Augen bekommen und mir gedacht: WTF? Entweder bin ich zu doof, zu schissig, oder Mailserver sind nix mehr für Hobbyhoster. Eine Anfrage hier schien das Letzte zu bestätigen. Mailtechnisch läuft es auf eine Monokultur weniger Anbieter hinaus.

Dieses habe ich nun meinen Kunden / Patienten schonend beigebracht. Einige sind sich anscheinend über den Ernst der Lage noch nicht so bewusst. Aber das soll nun nicht mehr mein Problem sein. Dafür habe ich 15 Jahre fast komplett kostenlosen Service betrieben. Also, wer meckert, fliegt...

Gleichzeitig war mal wieder Distriwechsel angesagt. Und da VSerververträge inzwischen monatlich gekündigt werden können, gleich ein Serverwechsel. Hat den Vorteil, dass man in aller Ruhe umschichten kann. Diesmal kein Image des Providers genommen sondern puristisch ein Debian Netinstall eingelegt. Dabei habe ich mich dann auch gefragt, brauche ich überhaupt noch ein Admin-Frontend wie Froxlor. Und was macht das so im Hintergrund? Ich habe mich dann mal etwas tiefer in die Funktion von Froxlor eingearbeitet und muss sagen, auch wenn es recht stabil läuft, es ist inzwischen aufgebläht und unübersichtlich geworden. Zumal es an einigen Stellen auch sehr unflexibel ist, sodass man doch wieder viel Handarbeit machen muss. Mailserver z.B. würde ich so nicht mehr nutzen wollen. Und die Unterstützung von Letsencrypt lässt auch zu wünschen übrig. Klar, wurde alles Stück für Stück angeflanscht. Wie so viele Projekte ist Froxlor ja auch eine One-Man-Show. Also ist meckern unangebracht.

Und so habe ich mich entschieden, back to the roots. Stinknormaler Webserver mit Apache2, weil ich das so gewohnt bin. Dazu die aktuelle PHP-Version und einen MariaDB-Server, weil es immer so war. ;) FTP-Server? Brauche ich nicht, geht alles mit SFTP. Jeder Kunde / Patient hat sein Verzeichnis und wird drauf festgenagelt. ufw ist auch Standard.

Die VHosts habe ich allesamt händisch erstellt. Letsencrypt läuft über Certbot mit API angeflanscht an meinen Domainprovider INWX. Das heisst, um die Verlängerung der Zertifikate muss ich mich nicht kümmern. Angemeldet habe ich sie auch alle über Kommandozeile. Wer auf meinem Server die Adminoberfläche hacken will, der wird keine finden.

Etwas stolz bin ich darauf, alle meine Domains nun mit einem Wildcard-Zertifikat versehen zu haben. Das erspart weitere Arbeit. Zudem der ganze händisch geklöppelte Karton jederzeit gebackuppt werden kann und im Falle des Falles woanders wieder zum Einsatz kommen kann. Das war bei Froxlor so eher nicht möglich. Distriwechsel bedeutete immer Inkompatiblität zur alten Version.

Was ich allerdings jetzt machen werde, ist die bash_history zu sichern, damit ich später gucken kann, wie ich das alles verzapft habe. Weil ob ich mir das alles so behalten kann, steht auf einem anderen Blatt. :)))))

Ich brauchte sowas jetzt auch mal als Selbstbestätigung. Meine Gesundheit hatte mich ja eine lange Zeit arg daran gehindert, tiefer in irgendetwas einzusteigen. Da kam der Google-Gau genau richtig.

Kleine Werbung am Rande, ich nutze die Dienste von Netcup seit Jahren und bis 100% zufrieden. Service habe ich noch nie gebraucht. Wegwerfserver für Kurzeinsätze, z.B. BBC-Serien ziehen, baue ich über ein Script über Amazon AWS EC2 auf.

#webserver #debian #letsencrypt #froxlor #google #mailserver #handarbeit #apache #netcup #altersack

5 Likes
One person like that
6 Likes
petrusko@diaspora-fr.org
Minos

Entrer une description pour l'image ici

Firefox OS phone - importer le certificat suite au 30 Septembre 2021

Etant toujours possesseur d'un smartphone ZTE OpenC sous Firefox OS, système plus du tout mis à jour car abandonné par Mozilla, l'appareil fonctionne encore correctement pour toutes les utilisations basiques telles que SMS, MMS, mails, surf web, alarmes, radios hertziennes, musiques mp3, etc.

Cependant, depuis le 30 Septembre 2021, date connue pour cette histoire d'expiration de certificat d'autorité de certification, les sites et autres services (serveur mail par exemple) qui sont basés sur Let's Encrypt, posent problème avec ce smartphone.

A l'époque, il était possible d'ajouter son certificat auto-signé dans le système de ce smartphone, et donc aujourd'hui il est possible d'utiliser cette technique pour insérer le nouveau certificat utilisé par Let's Encrypt, et ainsi décoincer nos bons vieux appareils :)

Merci les systèmes libres d'accès !!! Sinon ça n'aurait pas pu être possible :)

Technique trouvée ici :
https://mh8.mooo.com/www/leminos/index.php/certificats-auto-signes-import-dans-le-telephone

Mon ZTE OpenC recommence donc à pouvoir se reconnecter aux serveurs mails utilisant des certificats Let's Encrypt, comme celui qu'on peut utiliser sous #Yunohost et notre serveur en #auto-hebergement

TAGS: #letsencrypt #ZTE #OPENC #mozilla #firefoxos #firefox-os #firefox_os #informatique #smartphone #mobile #smartphonosaurus

2 Likes
9 Comments
2 Shares