<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Automatisierung on BSS Blog</title><link>https://blog.binarysystem.services/tags/automatisierung/</link><description>Recent content in Automatisierung on BSS Blog</description><generator>Hugo -- gohugo.io</generator><language>de-de</language><lastBuildDate>Wed, 18 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.binarysystem.services/tags/automatisierung/index.xml" rel="self" type="application/rss+xml"/><item><title>SSL-Zertifikate nur noch 200 Tage gültig: Was Unternehmen jetzt tun müssen</title><link>https://blog.binarysystem.services/posts/ssl-zertifikate-200-tage/</link><pubDate>Wed, 18 Mar 2026 00:00:00 +0000</pubDate><guid>https://blog.binarysystem.services/posts/ssl-zertifikate-200-tage/</guid><description>Seit dem 15. März 2026 gilt eine neue Regel für SSL/TLS-Zertifikate: Die maximale Gültigkeitsdauer wurde von zuvor 398 Tagen auf 200 Tage halbiert. Was zunächst wie eine technische Randnotiz klingt, hat weitreichende Konsequenzen für Unternehmen jeder Größe. Wer seine Zertifikate noch manuell verwaltet, steht jetzt vor einem ernsthaften Problem.
Warum wurde die Gültigkeitsdauer verkürzt? Der Schritt kam nicht überraschend. Das CA/Browser Forum, das die Standards für Zertifizierungsstellen und Browser festlegt, hat die schrittweise Verkürzung der Zertifikatslaufzeiten seit Jahren vorangetrieben.</description></item><item><title>Infrastructure as Code im Homelab: Nie wieder manuell konfigurieren</title><link>https://blog.binarysystem.services/posts/homelab-as-code/</link><pubDate>Wed, 28 Jan 2026 00:00:00 +0000</pubDate><guid>https://blog.binarysystem.services/posts/homelab-as-code/</guid><description>Das Problem mit manuellen Konfigurationen Kennt man das Gefühl? Ein Server läuft seit Monaten stabil. Man erinnert sich vage, dass man damals irgendwelche Einstellungen vorgenommen hat – welche genau, das weiß man nicht mehr. Dann stirbt die SSD, der Container lässt sich nicht mehr starten, oder man möchte einfach die Konfiguration auf eine neue Maschine übertragen.
Stunden vergehen. Man durchsucht alte Terminal-Historien, halbvergessene Notizen, veraltete Dokumentationen. Am Ende hat man etwas, das halbwegs funktioniert – aber identisch mit dem Original ist es nicht.</description></item><item><title>n8n: Workflow-Automatisierung selbst hosten — Einführung und erste Automationen</title><link>https://blog.binarysystem.services/posts/n8n-workflow-automatisierung/</link><pubDate>Thu, 15 Jan 2026 00:00:00 +0000</pubDate><guid>https://blog.binarysystem.services/posts/n8n-workflow-automatisierung/</guid><description>Cloudbasierte Automatisierungsplattformen sind praktisch — bis man merkt, dass sensible Geschäftsdaten durch Server im Ausland fließen, die monatlichen Kosten bei wachsenden Workflows explodieren oder ein Anbieter seine API-Anbindungen ändert. n8n löst alle drei Probleme: Open Source, selbst gehostet, keine Nutzungsgrenzen.
Dieser Guide zeigt, wie man n8n per Docker aufsetzen und erste sinnvolle Automationen für den KMU-Alltag bauen kann.
Was ist n8n? n8n (ausgesprochen &amp;quot;nodemation&amp;quot;) ist eine Open-Source-Workflow-Automatisierungsplattform mit einer visuellen Oberfläche.</description></item></channel></rss>