mastodontech.de ist einer von vielen unabhängigen Mastodon-Servern, mit dem du dich im Fediverse beteiligen kannst.
Offen für alle (über 16) und bereitgestellt von Markus'Blog

Serverstatistik:

1,5 Tsd.
aktive Profile

#tls

5 Beiträge5 Beteiligte0 Beiträge heute
ADMIN magazine<p>Let's Encrypt issues its first IP address certificate<br><a href="https://www.admin-magazine.com/News/Let-s-Encrypt-Issues-First-IP-Address-Certificate?utm_source=mam" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">admin-magazine.com/News/Let-s-</span><span class="invisible">Encrypt-Issues-First-IP-Address-Certificate?utm_source=mam</span></a><br><a href="https://hachyderm.io/tags/IPAddress" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPAddress</span></a> <a href="https://hachyderm.io/tags/certificate" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>certificate</span></a> <a href="https://hachyderm.io/tags/LetsEncrypt" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LetsEncrypt</span></a> <a href="https://hachyderm.io/tags/certs" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>certs</span></a> <a href="https://hachyderm.io/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a></p>
Prof. Dr. Dennis-Kenji Kipker<p>Auch <a href="https://chaos.social/tags/Traktoren" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Traktoren</span></a> sind nur <a href="https://chaos.social/tags/Computer" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Computer</span></a> - schlecht programmierte Computer: </p><p>Auf der Blackhat ist es Sicherheitsforschern gelungen, vernetzte Traktoren weltweit zu kompromittieren.</p><p>Erschütternd ist, dass es an den absoluten Basics für sichere <a href="https://chaos.social/tags/Software" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Software</span></a>-Entwicklung fehlt: Über einen schlecht gesicherten Mechanismus für over-the-air-Updates können die aus der <a href="https://chaos.social/tags/Cloud" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Cloud</span></a> empfangenen Daten einfach ausgetauscht werden, denn es gibt weder eine <a href="https://chaos.social/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a>-Verschlüsselung noch <a href="https://chaos.social/tags/Signaturen" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Signaturen</span></a>:</p><p><a href="https://www.darkreading.com/cloud-security/hackers-hay-smart-tractors-vulnerable-takeover" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://www.</span><span class="ellipsis">darkreading.com/cloud-security</span><span class="invisible">/hackers-hay-smart-tractors-vulnerable-takeover</span></a></p>
Ben Hardill<p>That will be a no.</p><p>Which is a shame as I want to use SNI in the back end but also make use of AWS issued certificates and the NLB TLS integration since there is no easy way to get a cert from the AWS Certificate Manager to a EKS Secret</p><p><a href="https://bluetoot.hardill.me.uk/tags/AWS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>AWS</span></a> <a href="https://bluetoot.hardill.me.uk/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> <a href="https://bluetoot.hardill.me.uk/tags/Certificates" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Certificates</span></a> <a href="https://bluetoot.hardill.me.uk/tags/SNI" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SNI</span></a></p>
Ben Hardill<p>Testing a theory on AWS, does a NLB terminating TLS forward the SNI header if the backend is also TLS?</p><p>Will know once AWS has finished pulling my test container.</p><p><a href="https://bluetoot.hardill.me.uk/tags/AWS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>AWS</span></a> <a href="https://bluetoot.hardill.me.uk/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> <a href="https://bluetoot.hardill.me.uk/tags/Certificates" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Certificates</span></a> <a href="https://bluetoot.hardill.me.uk/tags/SNI" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SNI</span></a></p>
Kevin Karhan :verified:<p><span class="h-card" translate="no"><a href="https://oldbytes.space/@drscriptt" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>drscriptt</span></a></span> granted, we all want <code>203.0.113.1</code>¹ to have <a href="https://infosec.space/tags/SSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SSL</span></a> / <a href="https://infosec.space/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> (even if it's just <span class="h-card" translate="no"><a href="https://infosec.exchange/@letsencrypt" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>letsencrypt</span></a></span> ) work than not work or have no <a href="https://infosec.space/tags/encryption" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>encryption</span></a>.</p><ul><li>That is not up for debate!</li></ul><p>I just think that this will <em>reward previously standards-violating behaviours</em> when i.e. <code>Xavier Sample Solutions</code> don't get nudged to use i.e. <code>api.solutions.example</code>² but can just use their IP addresses.</p><ul><li>Feels like companies take pride in copying <a href="https://infosec.space/tags/ClownFlare" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ClownFlare</span></a>'s <a href="https://infosec.space/tags/EgoTrip" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>EgoTrip</span></a> who put their <a href="https://infosec.space/tags/DNS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DNS</span></a> &amp; <a href="https://infosec.space/tags/domain" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>domain</span></a> on <a href="https://1.1.1.1" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">1.1.1.1</span><span class="invisible"></span></a> …</li></ul><p>¹ Example as per <a href="https://datatracker.ietf.org/doc/rfc5737/" rel="nofollow noopener" target="_blank">RFC5737</a> <br>² Example as per <a href="https://www.rfc-editor.org/rfc/rfc2606" rel="nofollow noopener" target="_blank">RFC2606</a></p>
d0rk ✅<p><a href="https://mastodon.social/tags/Apple" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Apple</span></a> <a href="https://mastodon.social/tags/Mail" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Mail</span></a>.app + <a href="https://mastodon.social/tags/Notes" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Notes</span></a>.app still use <a href="https://mastodon.social/tags/STARTTLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>STARTTLS</span></a> <a href="https://mastodon.social/tags/IMAP" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IMAP</span></a> protocol as a default?</p><p>Did a "lsof -i Pn" on my Macbook to learn that Mail used for my providers both port 143 (insecure STARTTLS) + port 993 (<a href="https://mastodon.social/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a>). For sure I didn't explicitly configure this.</p><p>The checkbox in Accounts =&gt; Advanced and then ~"configure connection preferences automatically" is the culprit. Unchecking that, choose port 993 instead of 143 , restart the Mail.app (and Notes.app) everything is fine.</p><p>@ Apple : <a href="https://mastodon.social/tags/wtf" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>wtf</span></a> ?</p>
Neil Craig<p>Does anyone know of a table of data which shows PKI CA root certs and which devices/clients they are compatible with? (i.e. which devices/clients include each root cert in their default trust store)</p><p>I think I have asked about this in the past. It'd be incredibly useful.</p><p><a href="https://mastodon.social/tags/PKI" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PKI</span></a> <a href="https://mastodon.social/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> <a href="https://mastodon.social/tags/InfoSec" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>InfoSec</span></a> <a href="https://mastodon.social/tags/WebDev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>WebDev</span></a></p>
Ben Hardill<p>Anybody worked out if it's possible to access AWS Certificate Manager certs in EKS Kubernetes as a TLS Secret? (I need to terminate in the pod not the LoadBalancer to access SNI)</p><p>It feels like it should be possible with the Secrets Store CSI driver with the AWS plugin, but it looks it only has access to AWS Secrets Manager. I don't really want to have to export and import every time they need renewing</p><p><a href="https://bluetoot.hardill.me.uk/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> <a href="https://bluetoot.hardill.me.uk/tags/AWS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>AWS</span></a> <a href="https://bluetoot.hardill.me.uk/tags/EKS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>EKS</span></a> <a href="https://bluetoot.hardill.me.uk/tags/kubernetes" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>kubernetes</span></a> <a href="https://bluetoot.hardill.me.uk/tags/Secrets" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Secrets</span></a> <a href="https://bluetoot.hardill.me.uk/tags/k8s" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>k8s</span></a></p>
Risotto Bias<p>wonder if the <a href="https://toot.risottobias.org/tags/SmallStep" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SmallStep</span></a> folks have made a "make your own tiny CA" that you can install client side such that you only trust the CA to issue certs for a particular domain. (Name Constraints extension support for e.g. Firefox)</p><p>e.g., only trusting a CA for certs of *.example.com or something.</p><p><a href="https://toot.risottobias.org/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> <a href="https://toot.risottobias.org/tags/cryptography" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>cryptography</span></a> <a href="https://toot.risottobias.org/tags/PKI" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>PKI</span></a> <a href="https://toot.risottobias.org/tags/certificatetransparency" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>certificatetransparency</span></a> <a href="https://toot.risottobias.org/tags/firefox" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>firefox</span></a></p>
Hacker News<p>You Should Run a Certificate Transparency Log</p><p><a href="https://words.filippo.io/run-sunlight/" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">words.filippo.io/run-sunlight/</span><span class="invisible"></span></a></p><p><a href="https://mastodon.social/tags/HackerNews" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>HackerNews</span></a> <a href="https://mastodon.social/tags/CertificateTransparency" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CertificateTransparency</span></a> <a href="https://mastodon.social/tags/CertificateLog" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CertificateLog</span></a> <a href="https://mastodon.social/tags/Cybersecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Cybersecurity</span></a> <a href="https://mastodon.social/tags/WebSecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>WebSecurity</span></a> <a href="https://mastodon.social/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a></p>
CybersecKyle<p><span class="h-card" translate="no"><a href="https://chaos.social/@farshidhakimy" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>farshidhakimy</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.ar.al/@aral" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>aral</span></a></span> Absolutely — you're right, this isn’t a brand-new concept. Cloudflare's cert on <a href="https://1.1.1.1" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">1.1.1.1</span><span class="invisible"></span></a> is a great example of a legitimate use case for IP-based certificates, especially in infrastructure-focused services like public DNS.</p><p>And yes, other CAs have issued certs for IP addresses before Let's Encrypt started doing it — so it’s not unprecedented. The shift here is more about accessibility and scale. Let’s Encrypt offering free certs for public IPs means this capability is now much more widely available, even to actors who previously didn’t have the budget or motivation to go through commercial CAs.</p><p>That’s where the risk discussion comes in — not that certs for IPs are inherently bad, but that easier issuance could lower the barrier for phishing kits, command-and-control servers, or shady hosts to appear more “legitimate” with a valid HTTPS padlock, especially in contexts where URLs are masked or shortened.</p><p>So yeah, not panic-worthy — just something worth watching as it scales.</p><p><a href="https://infosec.exchange/tags/CyberSecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CyberSecurity</span></a> <a href="https://infosec.exchange/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> <a href="https://infosec.exchange/tags/LetsEncrypt" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LetsEncrypt</span></a></p>
CybersecKyle<p><span class="h-card" translate="no"><a href="https://mastodon.ar.al/@aral" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>aral</span></a></span> Great point — and I agree that most users would be suspicious if they saw an IP address like 89.72.4.2 instead of a familiar domain like mybank.com. The concern raised in the article, though, was more about scenarios where users don’t see the link clearly — such as in emails, PDFs, or messaging apps where URLs may be masked behind anchor text or shortened links. For example, a phishing email might show a link that says “View Invoice” but actually points to https: //203.0.113.10/login.</p><p>Experienced users like you and I know to hover over links, check certificate info, or inspect the address bar. But many users don’t do that — or worse, they click links without verifying anything. According to the Verizon DBIR and other phishing studies, this is still one of the top attack vectors today.</p><p>Also, I don’t think the article was arguing against IP certs outright — just highlighting that, like with any new capability, there's potential for abuse that the broader public (and infosec community) should be aware of.</p><p><a href="https://infosec.exchange/tags/CyberSecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CyberSecurity</span></a> <a href="https://infosec.exchange/tags/Phishing" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Phishing</span></a> <a href="https://infosec.exchange/tags/DigitalTrust" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>DigitalTrust</span></a> <a href="https://infosec.exchange/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a></p>
Mitex Leo<p>Big news from Let's Encrypt! Since 2015, there have been requests for certificates for IP addresses—a rare offering among certificate authorities. Today, they've issued their first certificate for an IP address! As announced earlier this year, this feature is now being rolled out gradually to subscribers. </p><p><a href="https://letsencrypt.org/2025/07/01/issuing-our-first-ip-address-certificate/" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">letsencrypt.org/2025/07/01/iss</span><span class="invisible">uing-our-first-ip-address-certificate/</span></a></p><p><a href="https://mitexleo.one/tags/letsencrypt" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>letsencrypt</span></a> <a href="https://mitexleo.one/tags/ssl" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>ssl</span></a> <a href="https://mitexleo.one/tags/tls" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>tls</span></a> <a href="https://mitexleo.one/tags/infosec" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>infosec</span></a> <a href="https://mitexleo.one/tags/selfhosted" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>selfhosted</span></a> <a href="https://mitexleo.one/tags/security" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>security</span></a></p>
Wesley Moore<p>Urgh I _still_ dislike dealing with TLS certs. The certificate on <a href="https://au.mirror.7bit.org/" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">au.mirror.7bit.org/</span><span class="invisible"></span></a> expired earlier in the week, which was surprising because I thought I'd set everything up to automatically renew. Turns out I had, but I'd forgotten to include a Lego renew hook to restart nginx when the cert was renewed. Apparently I also didn't have monitoring of this cert (I do now) :facepalm:</p><p>Why is it that only Caddy and Traefik seem to have built in ACME clients?</p><p><a href="https://mastodon.decentralised.social/tags/acme" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>acme</span></a> <a href="https://mastodon.decentralised.social/tags/tls" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>tls</span></a> <a href="https://mastodon.decentralised.social/tags/https" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>https</span></a> <a href="https://mastodon.decentralised.social/tags/LetsEncrypt" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LetsEncrypt</span></a></p>
Ben Hardill<p>Anybody know if a AWS NLB when doing TLS termination will pass on the SNI to the service behind if doing so over TLS?</p><p><a href="https://bluetoot.hardill.me.uk/tags/AWS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>AWS</span></a> <a href="https://bluetoot.hardill.me.uk/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> <a href="https://bluetoot.hardill.me.uk/tags/LoadBalancer" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LoadBalancer</span></a></p>
Inautilo<p><a href="https://mastodon.social/tags/Development" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Development</span></a> <a href="https://mastodon.social/tags/Announcements" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Announcements</span></a><br>Our first IP address certificate · Let’s Encrypt starts rolling out the new option <a href="https://ilo.im/16530s" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">ilo.im/16530s</span><span class="invisible"></span></a></p><p>_____<br><a href="https://mastodon.social/tags/LetsEncrypt" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LetsEncrypt</span></a> <a href="https://mastodon.social/tags/CA" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CA</span></a> <a href="https://mastodon.social/tags/IpAddress" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IpAddress</span></a> <a href="https://mastodon.social/tags/Certificate" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Certificate</span></a> <a href="https://mastodon.social/tags/SSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SSL</span></a> <a href="https://mastodon.social/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> <a href="https://mastodon.social/tags/HTTPS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>HTTPS</span></a> <a href="https://mastodon.social/tags/WebDev" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>WebDev</span></a> <a href="https://mastodon.social/tags/Frontend" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Frontend</span></a> <a href="https://mastodon.social/tags/Backend" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Backend</span></a></p>
Sascha Stumpler<p>Security Review for Microsoft Edge version 138 <a href="http://dlvr.it/TLbPNQ" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">http://</span><span class="">dlvr.it/TLbPNQ</span><span class="invisible"></span></a> <a href="https://hessen.social/tags/MicrosoftEdge" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>MicrosoftEdge</span></a> <a href="https://hessen.social/tags/CyberSecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>CyberSecurity</span></a> <a href="https://hessen.social/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> <a href="https://hessen.social/tags/Privacy" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>Privacy</span></a></p>
Aral Balkan<p>Introducing Web Numbers</p><p>Domains? Where we’re going, we don’t need domains!</p><p>Get ready for an exciting new (old?) way to address (small) web sites in 2026.</p><p><a href="https://ar.al/2025/06/25/web-numbers/" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="">ar.al/2025/06/25/web-numbers/</span><span class="invisible"></span></a></p><p>💕</p><p>(Thanks to <span class="h-card" translate="no"><a href="https://infosec.exchange/@letsencrypt" class="u-url mention" rel="nofollow noopener" target="_blank">@<span>letsencrypt</span></a></span>.)</p><p><a href="https://mastodon.ar.al/tags/WebNumbers" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>WebNumbers</span></a> <a href="https://mastodon.ar.al/tags/SmallWeb" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SmallWeb</span></a> <a href="https://mastodon.ar.al/tags/domainNames" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>domainNames</span></a> <a href="https://mastodon.ar.al/tags/IPAddresses" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>IPAddresses</span></a> <a href="https://mastodon.ar.al/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>TLS</span></a> <a href="https://mastodon.ar.al/tags/HTTPS" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>HTTPS</span></a> <a href="https://mastodon.ar.al/tags/LetsEncrypt" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>LetsEncrypt</span></a> <a href="https://mastodon.ar.al/tags/web" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>web</span></a> <a href="https://mastodon.ar.al/tags/decentralisation" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>decentralisation</span></a> <a href="https://mastodon.ar.al/tags/SmallTech" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>SmallTech</span></a></p>
Ben Hardill<p>I'm seeing something strange with HTTPS requests from docker containers after docker upgrade to latest (28.2.2).</p><p>Docker compose, app containers and a nginx proxying for them all. One container trying to reach another via nginx external hostname.</p><p>Both NodeJS and curl fail to make the request with:</p><p> TLS connect error: error:00000000:lib(0)::reason(0)<br>* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to xxxx.xxxx.com:443</p><p>Same request outside container works just fine.</p><p><a href="https://bluetoot.hardill.me.uk/tags/docker" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>docker</span></a> <a href="https://bluetoot.hardill.me.uk/tags/tls" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>tls</span></a> <a href="https://bluetoot.hardill.me.uk/tags/https" class="mention hashtag" rel="nofollow noopener" target="_blank">#<span>https</span></a></p>
Kevin Veen-Birkenbach<p><strong>CyMaIS: 100 % DSGVO-konform</strong></p> <p>Die Datenschutz-Grundverordnung (DSGVO) schreibt strenge Vorgaben vor, wenn es um den Umgang mit personenbezogenen Daten geht. Wer seine Unternehmensdaten und die persönlichen Informationen von Mitarbeitenden oder Kund:innen schützen möchte, braucht mehr als nur eine Standard-Cloud. CyMaIS erfüllt nicht nur sämtliche DSGVO-Anforderungen, sondern geht mit ausgefeilten Sicherheitskonzepten und flexibler Infrastruktur noch einen Schritt weiter.</p> <p> […]</p> <p><a href="https://blog.cymais.cloud/blog/2025/06/19/cymais-100-dsgvo-konform/" rel="nofollow noopener" translate="no" target="_blank"><span class="invisible">https://</span><span class="ellipsis">blog.cymais.cloud/blog/2025/06</span><span class="invisible">/19/cymais-100-dsgvo-konform/</span></a></p>