mindly.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Mindly.Social is an English speaking, friendly Mastodon instance created for people who want to use their brains and their hearts to make social networking more social. 🧠💖

Administered by:

Server stats:

1.2K
active users

#pki

3 posts3 participants0 posts today

Just spent some quality time figuring out why HTTPS requests with incorrect system time would fail - even though the time was between the certificate NotBefore and NotAfter.

OCSP stapling was the culprit. This adds a more strict "window of system time validity" due to the way the protocol works. The obvious reason for the smallish window is to allow caching, while reducing the replay attack possibilities. Thus, the system clock can't be backdated more than a few hours, regardless of certificate NotBefore. The system time can be more off towards the future.

In our use case, we don't need to worry about revocation and hence we will just kill OCSP use. With this, we will still have the limits set by the certificate NotBefore and NotAfter, but at least they're more predictable and somewhat laxer.

Replied in thread

@Xeniax Totally nerdsniped :D I'd love to be a part of the study.

I don't think that #KeyServers are dead. I think they evolved into Verifying Key Servers (VKS), like the one run by a few folks from the OpenPGP ecosystem at keys.openpgp.org/about . More generally, I believe that #PGP / #GPG / #OpenPGP retains important use-cases where accountability is prioritized, as contrasted with ecosystems (like #Matrix, #SignalMessenger) where deniability (and Perfect Forward Secrecy generally) is prioritized. Further, PGP can still serve to bootstrap those other ecosystems by way of signature notations (see the #KeyOxide project).

Ultimately, the needs of asynchronous and synchronous cryptographic systems are, at certain design points, mutually exclusive (in my amateur estimation, anyway). I don't think that implies that email encryption is somehow a dead-end or pointless. Email merely, by virtue of being an asynchronous protocol, cannot meaningfully offer PFS (or can it? Some smart people over at crypto.stackexchange.com seem to think there might be papers floating around that can get at it: crypto.stackexchange.com/quest).

To me, the killer feature of PGP is actually not encryption per se. It's certification, signatures, and authentication/authorization. I'm more concerned with "so-and-so definitely said/attested to this" than "i need to keep what so-and-so said strictly private/confidential forever and ever." What smaller countries like Croatia have done with #PKI leaves me green with envy.

keys.openpgp.orgkeys.openpgp.org

Is today #FediHire Friday? Sure looks like it!

What I'm looking for: A senior level, individual contributor role supporting Windows, Active Directory, Certificates, PKI, Azure, and information security in a large environment. Interested in relocating outside of the US. I like to solve weird problems and make computers run smoothly. I want to help others use technology effectively.

My main focus the last few years has been rebuilding and modernizing a struggling certificate management team. That includes growing the team to meet our company needs, migrating our AD-integrated private PKI stack, getting a handle on our web PKI consumption, and making massive improvements to our certificate lifecycle management platform. I supported and advised our CyberSec and Desktop teams as we rolled out multi-factor authentication to 50,000 employees and contractors across the US. My background in understanding deep computer fundamentals, talent for quickly grasping nuances of larger systems, and calmness in a crisis have contributed to quickly resolving major technology outages regardless of root cause.

This role hasn't been exclusively technical. A big part of my current job is building relationships with our developers to help them understand how certificates work, the responsible ways to use them, and what our relevant internal policies are. I've been training and teaching junior and mid-level engineers both practical PKI concepts and our specific enterprise requirements. I've gotten to spend some time with upper management to both explain the immediate challenges we've had and the plans we can implement improve our infrastructure, reducing costs and outages.

While this position has been focused on certs and how to use them, I'm very comfortable considering a technical leadership role for Windows (server and desktop) administration and Active Directory. I also have some good experience with Azure and virtualization platforms, but they haven't been my daily focus for several years.

My current employer is direct retail for general public consumers. I've also worked in banking/finance, manufacturing, and architecture firms. The common thread is I love to help people leverage technology for their goals, to help them be more effective.

In my personnel/volunteer time I've done very similar: working backstage with lights/sounds/projections so live performers can do their best.

Right now I'm in Syracuse, New York (about five hours from NYC), but I'm open to relocation/migration anywhere in the world.

PMs open if you want to talk details. Boosts/reshares appreciated.

🚨 Fixing the PKI Mess: CAA + Your Own CA via DNS 🚨

Right now, any CA can issue a certificate for your domain. Even if you set a CAA record (`issue "letsencrypt.org"`), it only controls *who* can issue, not what cert is valid. This is broken.

🔐 What if we could fix this using DNS?

#Introducing CAA+CA Fingerprint: Self-Sovereign Certificate Authority
Instead of just saying *which CA can issue*, you publish your own CA's fingerprint in DNS. If your CA issues a cert for `awesomecars.com`, browsers should validate it against the DNS-published CA key.

🔥 How It Works
You run your own CA (because why trust the cartel?). You then publish:
1️⃣ A CAA record specifying your own CA (with a fingerprint! 🔥)
2️⃣ A DNS record with your CA’s public key (like DKIM but for TLS!)

🔹 Example DNS Setup for `awesomecars.com`:
```
awesomecars.com. IN CAA 0 issue "pki.awesomecars.com; sha256=abcd1234..."
pki.awesomecars.com. IN CERT 6 0 0 (--BEGIN CERTIFICATE-- ....)
```
Now, only certs signed by your CA are valid for `awesomecars.com`, even if another CA is tricked into issuing a rogue cert. No more CA hijacking!

🚀 Why Is This Better Than the Current CA Model?
✅ Self-Sovereign Identity: If you own the domain, you should own its PKI.
✅ Prevents Rogue Certs: No government or rogue CA can fake a cert for your domain.
✅ Works Like DKIM for Email: Your CA’s public key is stored in DNSSEC-protected records, just like DKIM keys for email signing.
✅ No More External Trust Issues: You control your CA entirely, instead of relying on Google’s CA store.
✅ Perfect for Self-Hosting & Internal Networks: No need for external CA trust—your DNS is your trust model.

🔥 Why Isn’t This a Thing Already?
Big Tech hates this idea because it removes their control:
❌ Google wants Certificate Transparency (CT), where they control which certs are logged.
❌ Commercial CAs make $$$ selling certs. This kills their business.
❌ DNSSEC adoption is intentionally kept low by the same companies who don’t want this to succeed.

Browsers refuse to support TLSA for the same reason—they want centralized CA trust, not self-hosted PKI.

🔗 Who Needs to Implement This?
🚀 Self-hosters & Homelabs: Use this for your own infrastructure.
🚀 Email providers: Stop relying on public CAs!
🚀 Privacy-focused projects (Tor, Matrix, XMPP, Fediverse, etc.): A true decentralized PKI alternative.
🚀 Fediverse devs: Let’s push for DNS-based CA validation!

What do you think? Would you trust your own CA in DNS over some random commercial CA?

🔁 Boost this if you want a decentralized PKI revolution!

🔥 This keeps the focus on self-hosting your own CA, highlights the security flaws of current PKI, and calls out Big Tech’s resistance to decentralized trust.

I went to #38c3 and left my laptop unplugged. Its clock stopped and it think it's December 27.

Of course, web site certificates are invalid. But why do I get #OCSP errors in #Firefox when I clearly disabled OCSP querying?

> An error occurred during a connection to search.brave.com. The OCSP response is not yet valid (contains a date in the future).

Is this a data leak about domains I visit? I'd search for info but #Brave doesn't load :P

#privacy#tls#pki

Every year around this time, I recreate all the certificates for my home network. This time I will also renew my private root and sub CA as I want to do a little optimization. In 2016 I started running my own small #PKI on the command line with #OpenSSL. Many thanks to the following resources, from which I have learned a lot:

feistyduck.com/books/openssl-c
github.com/ivanr/bulletproof-t
github.com/ivanr/bulletproof-t
jamielinux.com/docs/openssl-ce
cabforum.org/working-groups/se

www.feistyduck.comOpenSSL Cookbook | Feisty Duck

Has anyone working with #msTeams and #PCIDSS managed to convince a credit card company that the public key encryption used to secure #teamsVoice calls is suitable to exempt a corporate network from being in-scope when taking CHD over a telephone call?

pcisecuritystandards.org/faq/a

PCI Security Standards Council · Frequently Asked QuestionBy mobeenx

Been thinking about what the key-trust part of decentralized "social PKI" should look like.

The individual part seems straightforward: A public key, and a history of key rotations (where each key signs a message revoking itself as latest, and endorsing the next public key as latest instead.)

But how do you trust someone else's key in the first place? (Including when they lose all data and have to recreate their identity, with a new key.)

I'm very tempted to say... we can leave that to implementations, with just some strong suggestions in the spec as to how to meet different users' different needs.

One implementation could just use TOFU and notify the user if something looks wrong. Another could participate in a key-gossip system, where useragents inform each other of identity/key relationships they've seen, allowing multipath resilience against MITM. And another could go full-on PGP key-party if it really wanted to, I guess.

Does this sound reasonable? Would love to hear feedback.

:boost_ok: