mathstodon.xyz is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Mastodon instance for maths people. We have LaTeX rendering in the web interface!

Server stats:

2.8K
active users

#pki

0 posts0 participants0 posts today

New Open-Source Tool Spotlight 🚨🚨🚨

Active Directory Certificate Services (AD CS) can be a goldmine if misconfigured. Tools like Certipy simplify enumeration and abuse, leveraging techniques like Shadow Credentials, Golden Certificates, and domain escalation paths (ESC1-ESC11). #CyberSecurity #RedTeam

Certipy's `shadow` command exemplifies ADCS weaknesses. By manipulating `msDS-KeyCredentialLink`, you can take over accounts via PKINIT. It's seamless but devastating for privilege escalation. #Pentesting #ActiveDirectory

Golden Certificates mimic Golden Tickets but target ADCS. Using a compromised CA private key, an attacker can forge certs for domain controllers or users. Certipy automates this process—caution with CA backups. #InfoSec #PKI

🔗 Project link on #GitHub 👉 github.com/ly4k/Certipy

#Infosec #Cybersecurity #Software #Technology #News #CTF #Cybersecuritycareer #hacking #redteam #blueteam #purpleteam #tips #opensource #cloudsecurity

✨
🔐 P.S. Found this helpful? Tap Follow for more cybersecurity tips and insights! I share weekly content for professionals and people who want to get into cyber. Happy hacking 💻🏴‍☠️

So it's official: TLS certificate lifetimes will reduce from the current max of 398 days to:
* 200 days in March 2026
* 100 days in March 2027
* 47 days in March 2029

For web servers/proxies etc. it's reasonably simple, at least for smaller orgs but for e.g. network kit it might be more of a challenge. Having a timeframe to aim at definitely focusses the mind!

Via @riskybiz / risky.biz/risky-bulletin-ca-b-

risky.bizRisky Bulletin: CA/B Forum approves 47-days TLS certs - Risky Business MediaThe CA/Browser Forum passed a ballot to reduce the maximum validity of TLS certificates from the current 398 days to just 47 days by 2029. [Read More]
#TLS#PKI#InfoSec
Continued thread

Specific schedule:

March 15, 2026 - Cert validity (and Domain Control Validation) limited to 200 days.
March 15, 2027 - Cert validity (and Domain Control Validation) limited to 100 days.
March 15, 2029 - Cert validity limited to 47 days and Domain Control Validation limited to 10 days.

There's gonna be a lot of complaints about this in change control meetings over the next year200 days.

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.

Предложение Mozilla по отзыву случайных сертификатов

Разработчики Mozilla выступили с интересным предложением по оздоровлению инфраструктуры сертификатов TLS и инфраструктуры открытых ключей (PKI) в целом. Среди прочего, Центрам Сертификации предлагается массово отзывать у пользователей сертификаты, чтобы подтолкнуть их к автоматизации. Для тестирования системы ежегодно отзыву подлежит 30 случайных сертификатов.

habr.com/ru/companies/globalsi

ХабрПредложение Mozilla по отзыву случайных сертификатовРазработчики Mozilla выступили с интересным предложением по оздоровлению инфраструктуры сертификатов TLS и инфраструктуры открытых ключей (PKI) в целом. Среди прочего, Центрам Сертификации...

🚨 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.

A question that just popped to my mind, reasonable input/debate welcome around it: "Let"s encrypt is a US based non profit organization, submitted to the "US Cloud Act", how could the EU laws (GDPR) be respected by EU or swiss companies (Proton, others) using "Let's encrypt" to secure the communication privacy, given it can lead way to massive TLS communication hijacks via emissions of website certs for CDN appearing to be the website that client (apps, web browser) communicates with using anonymous TLS.? Even more in this kind of context: noyb.eu/en/us-cloud-soon-illeg Any idea anyone? Where am I wrong in this line of thoughts? Why don't they use the EU approved eIDAS qualified certificate authorities (eidas.ec.europa.eu/efda/trust-) that ensure that the EU laws and GDPR are respected by the CAs? At least EU govs would have a little more control on what could happen to limit interferences? Why are browsers like mozilla not talking about this? I start to wonder if some blocks that did cut the ties with current Internet PKI & DNS infrastructrue to ensure that their people laws are respected by the technical infrastructure are not completely wrong to do so, given the US not going to a free people country direction anymore.

PS: Features like MS recall or CSAM are even more frightening from a personal freedom and corporate security perspective, since they use neural nets to sort the screenshots on laptop and label them for easier retrieval...
.
.
.#nyob #cloudact #TLS #PKI #gdpr

noyb.euUS Cloud soon illegal? Trump punches first hole in EU-US Data DealTrump paralysed the "Privacy and Civil Liberties Oversight Board" (PCLOB), a key element of the EU-US data transfer deal that allows EU-US data flows.