social.wildeboer.net is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mastodon instance for people with Wildeboer as their last name

Server stats:

2
active users

#letsencrypt

2 posts2 participants0 posts today

Thought experiment:

@letsencrypt offers certificates to encrypt the traffic between a website & your browser.

They reside in the US & thus are subject to the judiciary system of the US.

What are the possible risks for websites outside the US, given the current unstable political situation & administration? What type of damage could an executive order do? How could this be mitigated?

Boosts appreciated.

Fsck de overheid: "Het automatiseren van certificaatbeheer door de overheid op basis van ACME zorgt voor het efficiënter en betrouwbaarder verkrijgen, vernieuwen en intrekken van TLS-certificaten. Dit maakt de digitale overheid betrouwbaarder, wendbaarder en minder leveranciersafhankelijk", aldus de experts. "Daarnaast vermindert het gebruik van ACME de beheerlast voor het beheer van TLS-certificaten."
security.nl/posting/876900/ACM.

In een tijd waarin burgers, online, met steeds hogere betrouwbaarheid moeten authenticeren (o.a. voor online leeftijdsverificatie en binnenkort met eID's zoals EDIW/EUDIW), en de anonieme nepwebsites als paddenstoelen uit de grond schieten (*), is dit een *KRANKZINNIG* plan.

(*) Daarbij geen strobreed in de weggelegd door BigTech - integendeel: medeplichtigheid aan cybercrime is hun verdienmodel geworden.

Het grote risico hier zijn AitM- (Attacker in the Middle) aanvallen: nietsvermoedende mensen worden via een bericht of een Google zoekresultaat naar een nepwebsite gestuurd, die hen vraagt om bijv. een scan van hun paspoort te uploaden en een selfie-filmpje te maken.

Beide stuurt de nepwebsite echter dóór naar een echte website, zoals van een bank, bijv. om een lening af te sluiten. De AitM neemt dat geld op, waarna het slachtoffer opdraait voor de schuld.

Een ESSENTIËLE voorwaarde voor betrouwbare authenticatie is dat je de VERIFIEERDER kunt vertrouwen.

Of dat zo is, weet je nooit zeker (ook offline niet). Het beste alternatief is dat je weet *WIE* de verifieerder is, en hoe betrouwbaar diens identiteit is vaatgesteld. Dat is, zonder meer, vervelend en prijzig voor eigenaren van websites waar klanten, burgers of patiënten risicovolle transacties doen en/of er vertrouwelijke gegevens mee uitwisselen - maar enorm in het belang van bezoekers van dergelijke websites.

Betrouwbare authenticatie van (de juridisch aansprakelijke) eigenaar van een website m.b.v. een website-certificaat vormt *technisch* geen enkel probleem (dit *hadden* we al, maar is met een smoes gesloopt door Google).

In gratis certificaten, bijvoorbeeld van Let's Encrypt (zoals gebruikt door de nepwebsites in onderstaand plaatje) staat uitsluitend een volstrekt anonieme domeinnaam; je hebt dus geen idee wie verantwoordelijk is voor de website.

Juist bij overheidswebsites is het essentieel dat je weet dat het écht om een overheidswebsite gaat - iets dat bij de in het plaatje getoonde domeinnamen (ik heb de punt door + vervangen), zoals:

• afhandelen-belasting+com
• aflossen-belastingdienst+com

beslist *niet* het geval is.

En in de echte ggn.nl/contact/phishing/ kunt u voorbeelden zien van domeinnamen van nepwebsites, zoals ook te zien in onderstaand plaatje.

Kennelijk lukt het niemand om dergelijke criminele websites uit de lucht te halen, terwijl de misdadigers er probleemloos Let's Encrypt certificaten voor *blijven* verkrijgen - naast dat de naar phishing stinkende domeinnamen zonder blikken of blozen worden verhuurd en nooit worden ingetrokken. Dit is simpelweg de SNELSTE en GOEDKOOPSTE oplossing voor eigenaren van websites; de *BEZOEKERS* van die websites draaien op voor alle risico's.

Het onderstaande plaatje is van een Russische server, maar dit soort phishing websites vind je ook bij de vleet op door criminelen gehuurde servers van Google, Amazon, Microsoft, Digital Ocean, Cloudflare en kleinere westerse hostingbedrijven.

Ben ik nou ÉCHT DE ÉNIGE die vindt dat deze gecriminaliseerde puinhoop keihard moet worden aangepakt?

Zie mijn uitgebreide reactie in security.nl/posting/876914 (beginnend met eenvoudige uitleg wat een website-certificaat is).

Nb. naast certificaatuitgevers moeten ook browsers en het CA/B-forum op de schop. Doen we dit allemaal niet, dan wordt verder digitaliseren een gigantische puinhoop met steeds meer slachtoffers van identiteitsfraude.

For those who want a local (non-cloud) tool for checking TLS certificate expiration as a result of Let's Encrypt dropping support for expiration notices via email, here's a small shell script which will do it. It needs the OpenSSL command-line tool and an email sender (I use msmtp):

#!/bin/bash

MINIMUM_EXPIRY_DAYS={{ minimum_expiry_days }}
MINIMUM_EXPIRY=$((${MINIMUM_EXPIRY_DAYS} * 86400))

for cert in /etc/letsencrypt/live/*/cert.pem
do
echo Checking ${cert}
if openssl x509 -noout -in ${cert} -checkend ${MINIMUM_EXPIRY} > /dev/null
then
:
else
msmtp --read-envelope-from --read-recipients <<EOF
From: (sender address here)
To: (recipient address here)
Subject: Certificate Expiration Alert

${cert} will expire in fewer than ${MINIMUM_EXPIRY_DAYS} days.
EOF
fi
done

CC @letsencrypt @johns

New releases

• Kitten (rolling release)
• @small-tech/https version 5.3.2
• Auto Encrypt version 4.1.3

OCSP support has been reinstated in the server so existing sites with Let’s Encrypt certificates provisioned prior to the removal of the OCSP stapling requirement will not fail to load in Firefox.

Kitten servers in production will automatically update to this version in a few hours. You can also sign in to the Kitten settings page on your server and do a manual update to update Kitten immediately.

Thanks to @stefan and @s1r83r for bringing this to my attention. (mastodon.ar.al/@aral/113969540)

Aral’s fediverse serverAral Balkan (@aral@mastodon.ar.al)@s1r83r@pataterie.ca @stefan@gardenstate.social Thanks for the heads up, folks. So, here’s what’s happened: 1. Let’s Encrypt removed OCSP support and starting rejecting certificate requests that require OCSP stapling (a privacy feature that Kitten inherited from my Auto Encrypt module) for new server requests and will reject certificate renewal requests starting in May. 2. So I went ahead and removed the OCSP stapling requirement from the certificate requests Auto Encrypt makes to Let’s Encrypt. 3. I also removed OCSP support from the server. Makes sense, right? Sure does, until you consider what happens to servers with already-provisioned Let’s Encrypt certificates that have certificates that require OCSP stapling. (kitten.small-web.org’s certificate got renewed four days ago, before I’d released the updates.) *Doh!* 🤦‍♂️ Seems Safari and Chrom(ium) are fine with letting it pass. However, Firefox, (and correctly too, I might add), refuses to load the site. So I’m off to update Auto Encrypt to re-enable OCSP support with a note to disable it in May (by which time all certificates will have renewed anyway without the stapling requirement) and then issue new builds of @small-web/https and Kitten. Kitten servers should automatically upgrade and start working in Firefox in several hours. And you can also manually update them if you want to before then after I’ve announced the releases. Thanks again for letting me know. :kitten:💕 #Kitten #SmallWeb #AutoEncrypt #LetsEncrypt #TLS #SSL #HTTPS #OCSP

New Kitten release

• Upgrades to version 5.3.1 of @small-tech/https¹ which has version 4.1.2 of Auto Encrypt² that l removes OCSP stapling (because Let’s Encrypt has removed OCSP support).

Please upgrade your Kitten as soon as possible or any new Kitten servers you try to set up will fail and any certificate renewals for existing servers will start to fail in May.

kitten.small-web.org

(To upgrade, run `kitten update`. Your production servers will update automatically.)

Enjoy!

:kitten:💕

¹ npmjs.com/package/@small-tech/
² npmjs.com/package/@small-tech/

Continued thread

@small-tech/https version 5.3.0 released

• Uses Auto Encrypt 4.1.1 (removes OCSP stapling support because Let]s Encrypt has removed OCSP support).

npmjs.com/package/@small-tech/

This module is a drop in replacement for Node HTTPS module that automatically handles TLS certificate provisioning and renewal both at localhost (via Auto Encrypt Localhost¹) and at hostname (via Auto Encrypt with Let’s Encrypt certificates²).

So, this is how you create a HTTPS server in Node.js that uses this module and automatically handles TLS certificate provisioning and renewal for you both at localhost (during development) and at hostname (during production):

```js
import https from '@small-tech/https'

const server = https.createServer((request, response) => {
response.end('Hello, world!')
})

server.listen(443, () => {
console.log(' 🎉 Server running at https://localhost.')
})
```

(Yes, that’s it! I wrote a metric shit-tonne of meticulously-tested code so you don’t have to.) :)

💡 Note that the localhost certificate support via Auto Encrypt Localhost is 100% JavaScript and does NOT rely on an external binary like mkcert or certutil.

Needless to say, Kitten³ uses this module under the hood and it’s a big part of why Domain⁴ can deploy servers so easily that don’t require any day-to-day maintenance.

In case you’re wondering why I’m spending so much time releasing all these modules, it’s because I believe in sharing every brick of the house I’m building so others can easily build different houses if they want to. I’m not saying that what I’m building with Kitten, Domain, and Place⁵ will be the end all be all of the Small Web⁶ (the peer-to-peer web). And I want others to be able to experiment by building their own tools without having to go through the grueling development process I’ve had to in the past six years to build basic infrastructure.

Enjoy!

💕

¹ codeberg.org/small-tech/auto-e
² codeberg.org/small-tech/auto-e
³ kitten.small-web.org
codeberg.org/domain/app
codeberg.org/place/app
ar.al/2024/06/24/small-web-com

npm@small-tech/httpsA drop-in standard Node.js HTTPS module replacement with both automatic development-time (localhost) certificates via Auto Encrypt Localhost and automatic production certificates via Auto Encrypt.. Latest version: 5.3.0, last published: 16 minutes ago. Start using @small-tech/https in your project by running `npm i @small-tech/https`. There are 2 other projects in the npm registry using @small-tech/https.

Auto Encrypt version 4.1.0 released

• Removes OCSP stapling, as Let’s Encrypt is removing OCSP support.

If you’re already using Auto Encrypt upgrade before May or your certificate renewals will start to fail. Upgrade now if you want to get certificates for new domains as new certificate requests are already failing.

codeberg.org/small-tech/auto-e

Auto Encrypt automatically provisions and renews Let’s Encrypt TLS certificates on Node.js https servers (including Kitten¹, Polka, Express.js, etc.)

Regular Node.js HTTPS server (without Let’s Encrypt certificates):

```js
import https from 'node:https'
const server = https.createServer(…)
```

Auto Encrypt https server with automatic Let’s Encrypt certificates:

```js
import AutoEncrypt from '@small-tech/auto-encrypt'
const server = AutoEncrypt.https.createServer(…)
```

(Certificates are provisioned on first hit and automatically renewed 30 days before expiry.)

¹ kitten.small-web.org

Codeberg.orgauto-encryptAutomatically-provisioned TLS certificates for Node.js servers using Let’s Encrypt.

Let's Encrypt will discontinue sending expiration notification emails, and they can recommend

Red Sift Certificates Lite
Lite is the free tier of Red Sift Certificates, providing expiration monitoring for up to 250 certificates and 7-day email alerts to prevent downtime.

redsift.com/pulse-platform/cer

redsift.comNever miss an expiring certificate with Red Sift Certificates LiteLite is the free tier of Red Sift Certificates, providing expiration monitoring for up to 250 certificates and 7-day email alerts to prevent downtime.

Just released Node Pebble version 5.1.1

• Updated to Pebble version 2.7.0.

• Now also supports macOS and arm64 (because Pebble itself does).

codeberg.org/small-tech/node-p

Node Pebble is a Node.js wrapper for Let’s Encrypt’s¹ Pebble² that:

• Downloads the correct Pebble binary for your platform.

• Launches and manages a single Pebble process.

• Returns a reference to the same process on future calls (safe to include in multiple unit tests where order of tests is undetermined)

• Automatically patches Node.js’s TLS module to accept Pebble server’s test certificate as well as its dynamically-generated root and intermediary CA certificates.

¹ letsencrypt.org

² “A miniature version of Boulder, Pebble is a small RFC 8555 ACME test server not suited for a production certificate authority.” github.com/letsencrypt/pebble

Codeberg.orgnode-pebbleA Node.js wrapper for Let’s Encrypt’s Pebble (a small RFC 8555 ACME test server not suited for a production certificate authority)
#LetsEncrypt#TLS#SSL

So I guess Let’s Encrypt has decided what I’ll be working on today then…

letsencrypt.org/2024/12/05/end

(They’re ending OCSP stapling support. I’ll be updating Auto Encrypt¹ to remove OCSP support and then update @small-tech/https, which uses it, along with Auto Encrypt Localhost² to provide seamless TLS support regardless of whether you’re working in development or in production, and then update Site.js³ – deprecated but still used to serve some of our own sites at Small Technology Foundation⁴ – and Kitten⁵, with the latest @small-tech/https.)

¹ codeberg.org/small-tech/auto-e
² codeberg.org/small-tech/auto-e
³ codeberg.org/small-tech/https
small-tech.org
kitten.small-web.org

letsencrypt.orgEnding OCSP Support in 2025Earlier this year we announced our intent to provide certificate revocation information exclusively via Certificate Revocation Lists (CRLs), ending support for providing certificate revocation information via the Online Certificate Status Protocol (OCSP). Today we are providing a timeline for ending OCSP services: January 30, 2025 OCSP Must-Staple requests will fail, unless the requesting account has previously issued a certificate containing the OCSP Must Staple extension May 7, 2025 Prior to this date we will have added CRL URLs to certificates On this date we will drop OCSP URLs from certificates On this date all requests including the OCSP Must Staple extension will fail August 6, 2025 On this date we will turn off our OCSP responders Additionally, a very small percentage of our subscribers request certificates with the OCSP Must Staple Extension.

People have probably seen this before, and I have - but not to this extent.

All certificates that are public, are actually "streamed" to public databases, that in line with regulation set by CA's, browsers and other vendors.

What that means, is that if you issue (or buy) a certificate from a public CA - and you are only using it in an internal environment - people WILL know that you have a host with that particular CommonName somewhere.

I've issued a couple of certificates today, and since I host my own Authoritive DNS-servers, I am able to fully trace the requests coming into my DNS-zone.
Immediately after I've issued said certificates - I see many request arriving from all over the world, together with port-scans and all that shit.
And if you dont have a A-record for that particular hostname - the portscans will go directly against @.
All that from Cloud providers such as AWS, GCP, and shit.

Fascinating.

And if you want to check all the certificates that is issued - in real time, Check out "certstream"

certstream.calidog.io/

certstream.calidog.ioCertstream
Continued thread

For the geeks: Jekyll sites in git repos on my forgejo instance that runs as a rootless container. Forgejo runner on one of my RHEL (Red Hat Enterprise Linux) servers. A Forgejo action that runs Jekyll as another rootless container via to build the static sites and puts it in a git repo called web, which gets pulled to the /var/www directory on my ngninx web server. All with enabled. And every site with a certificate that gets updated automatically, when needed.