Fosstodon

Klaus FrankOh the <a href="https://chaos.social/tags/cabforum" class="mention hashtag" rel="nofollow noopener" target="_blank">#cabforum</a> also wants to sunset "certificate issuance for .arpa domains". At least one person following here uses an .arpa domain for their mastodon instance, so you probably want to checkout <a href="https://github.com/cabforum/servercert/pull/573" rel="nofollow noopener" translate="no" target="_blank">https://github.com/cabforum/servercert/pull/573</a> I guess.

CassanderSpecific 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 <del>year</del>200 days.<a href="https://infosec.exchange/tags/Certificate" class="mention hashtag" rel="nofollow noopener" target="_blank">#Certificate</a> <a href="https://infosec.exchange/tags/Certificate_Management" class="mention hashtag" rel="nofollow noopener" target="_blank">#Certificate_Management</a> <a href="https://infosec.exchange/tags/CABForum" class="mention hashtag" rel="nofollow noopener" target="_blank">#CABForum</a> <a href="https://infosec.exchange/tags/PKI" class="mention hashtag" rel="nofollow noopener" target="_blank">#PKI</a> <a href="https://infosec.exchange/tags/WebPKI" class="mention hashtag" rel="nofollow noopener" target="_blank">#WebPKI</a> <a href="https://infosec.exchange/tags/SSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#SSL</a> <a href="https://infosec.exchange/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#TLS</a>

CassanderBuckle up, kids. Automate your certificate rotations or die trying. WebPKI certificate validity period will be 47 days by 2029. <a href="https://www.bleepingcomputer.com/news/security/ssl-tls-certificate-lifespans-reduced-to-47-days-by-2029/" rel="nofollow noopener" translate="no" target="_blank">https://www.bleepingcomputer.com/news/security/ssl-tls-certificate-lifespans-reduced-to-47-days-by-2029/</a><a href="https://infosec.exchange/tags/Certificate" class="mention hashtag" rel="nofollow noopener" target="_blank">#Certificate</a> <a href="https://infosec.exchange/tags/Certificate_Management" class="mention hashtag" rel="nofollow noopener" target="_blank">#Certificate_Management</a> <a href="https://infosec.exchange/tags/CABForum" class="mention hashtag" rel="nofollow noopener" target="_blank">#CABForum</a> <a href="https://infosec.exchange/tags/PKI" class="mention hashtag" rel="nofollow noopener" target="_blank">#PKI</a> <a href="https://infosec.exchange/tags/WebPKI" class="mention hashtag" rel="nofollow noopener" target="_blank">#WebPKI</a> <a href="https://infosec.exchange/tags/SSL" class="mention hashtag" rel="nofollow noopener" target="_blank">#SSL</a> <a href="https://infosec.exchange/tags/TLS" class="mention hashtag" rel="nofollow noopener" target="_blank">#TLS</a>

Outvi V | 夕霧綴理推し🐧<a href="https://mk.outv.im/tags/CABForum" rel="nofollow noopener" target="_blank">#CABForum</a> passed SC-081v3 to shorten public <a href="https://mk.outv.im/tags/TLS" rel="nofollow noopener" target="_blank">#TLS</a> cerficiate validity to a eventual 47 days, creating a market for new jobs like "certificate renew specialist" and "technican for certificate error ignoring". This also brings light to a world of easier phishing cuz... you know, people don't get smarter in 1 or 2 days because some vote is passed. <a href="https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/9768xgUUfhQ" rel="nofollow noopener" target="_blank">https://groups.google.com/a/groups.cabforum.org/g/servercert-wg/c/9768xgUUfhQ</a>

Pyrzout :vm:Apple Enrages IT — 45-Day Cert Expiration Fury – Source: securityboulevard.com <a href="https://ciso2ciso.com/apple-enrages-it-45-day-cert-expiration-fury-source-securityboulevard-com/" rel="nofollow noopener" translate="no" target="_blank">https://ciso2ciso.com/apple-enrages-it-45-day-cert-expiration-fury-source-securityboulevard-com/</a> <a href="https://social.skynetcloud.site/tags/SecurityChallengesandOpportunitiesofRemoteWork" class="mention hashtag" rel="nofollow noopener" target="_blank">#SecurityChallengesandOpportunitiesofRemoteWork</a> <a href="https://social.skynetcloud.site/tags/DeepFakeandOtherSocialEngineeringTactics" class="mention hashtag" rel="nofollow noopener" target="_blank">#DeepFakeandOtherSocialEngineeringTactics</a> <a href="https://social.skynetcloud.site/tags/CertificateandKeyLifecycleManagement" class="mention hashtag" rel="nofollow noopener" target="_blank">#CertificateandKeyLifecycleManagement</a> #90-dayTLScertificatevalidity <a href="https://social.skynetcloud.site/tags/CertificateandKeyManagement" class="mention hashtag" rel="nofollow noopener" target="_blank">#CertificateandKeyManagement</a> <a href="https://social.skynetcloud.site/tags/IdentityandAccessManagement" class="mention hashtag" rel="nofollow noopener" target="_blank">#IdentityandAccessManagement</a> <a href="https://social.skynetcloud.site/tags/SecurityBoulevard" class="mention hashtag" rel="nofollow noopener" target="_blank">#SecurityBoulevard</a>(Original) <a href="https://social.skynetcloud.site/tags/rssfeedpostgeneratorecho" class="mention hashtag" rel="nofollow noopener" target="_blank">#rssfeedpostgeneratorecho</a> <a href="https://social.skynetcloud.site/tags/CertificateAutomation" class="mention hashtag" rel="nofollow noopener" target="_blank">#CertificateAutomation</a> <a href="https://social.skynetcloud.site/tags/ApplicationSecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#ApplicationSecurity</a> <a href="https://social.skynetcloud.site/tags/CABForum" class="mention hashtag" rel="nofollow noopener" target="_blank">#CABForum</a>

Jesse HarrisI see a lot of weeping, wailing, and gnashing of teeth over this proposal, but how do you think we get from "manually handle all of your certs in nightmare mode" to everything supporting ACME? You put a gun to the heads of the software vendors and equipment makers with a hard deadline. Not saying it won't suck for a while, especially with legacy systems, but that pain is decades of tech debt coming due. <a href="https://infosec.exchange/tags/cabforum" class="mention hashtag" rel="nofollow noopener" target="_blank">#cabforum</a> <a href="https://infosec.exchange/tags/certificates" class="mention hashtag" rel="nofollow noopener" target="_blank">#certificates</a> <a href="https://github.com/cabforum/servercert/pull/553" rel="nofollow noopener" translate="no" target="_blank">https://github.com/cabforum/servercert/pull/553</a>

adorferfor those who refused to automate their TLS certificate deployment so far: prepare for increased workload: " - Overall reduction of non-SAN validation reuse from 825 to 366 days - Overall reduction of SAN validation reuse from 398 days to 10 days [..] Overall reduction of maximum validity period from 398 days to 45 days These reductions are proposed to occur starting in September 2025 through September 2027 " <a href="https://github.com/cabforum/servercert/pull/553" rel="nofollow noopener" translate="no" target="_blank">https://github.com/cabforum/servercert/pull/553</a> <a href="https://chaos.social/tags/tls" class="mention hashtag" rel="nofollow noopener" target="_blank">#tls</a> <a href="https://chaos.social/tags/cabforum" class="mention hashtag" rel="nofollow noopener" target="_blank">#cabforum</a>

Erik van Straten(long) Wrong order: RPKI first - WebPKI never?

Erik van StratenUit het einde van <a href="https://security.nl/posting/854968" rel="nofollow noopener" translate="no" target="_blank">https://security.nl/posting/854968</a>: « Op internet wordt gebruikers DOELBEWUST de informatie onthouden waaruit zij, in nagenoeg alle gevallen, het verschil zouden kunnen zien tussen een filiaal van de Bijenkorf en een kofferbaksale uit een auto met gestolen kentekenplaten. | Het internet is ziek, doodziek - veroorzaakt door noobs, [...] en door Big Tech die meeverdient aan cybercriminaliteit. »<a href="https://infosec.exchange/tags/Phishing" class="mention hashtag" rel="nofollow noopener" target="_blank">#Phishing</a> <a href="https://infosec.exchange/tags/BigTech" class="mention hashtag" rel="nofollow noopener" target="_blank">#BigTech</a> <a href="https://infosec.exchange/tags/Browsers" class="mention hashtag" rel="nofollow noopener" target="_blank">#Browsers</a> <a href="https://infosec.exchange/tags/CABForum" class="mention hashtag" rel="nofollow noopener" target="_blank">#CABForum</a> <a href="https://infosec.exchange/tags/DV" class="mention hashtag" rel="nofollow noopener" target="_blank">#DV</a> <a href="https://infosec.exchange/tags/OV" class="mention hashtag" rel="nofollow noopener" target="_blank">#OV</a> <a href="https://infosec.exchange/tags/EV" class="mention hashtag" rel="nofollow noopener" target="_blank">#EV</a> <a href="https://infosec.exchange/tags/QWAC" class="mention hashtag" rel="nofollow noopener" target="_blank">#QWAC</a> <a href="https://infosec.exchange/tags/NepVanEchtKunnenOnderscheiden" class="mention hashtag" rel="nofollow noopener" target="_blank">#NepVanEchtKunnenOnderscheiden</a> <a href="https://infosec.exchange/tags/EchtVanNepKunnenOnderscheiden" class="mention hashtag" rel="nofollow noopener" target="_blank">#EchtVanNepKunnenOnderscheiden</a> <a href="https://infosec.exchange/tags/NepVanEchtOnderscheiden" class="mention hashtag" rel="nofollow noopener" target="_blank">#NepVanEchtOnderscheiden</a> <a href="https://infosec.exchange/tags/EchtVanNepOnderscheiden" class="mention hashtag" rel="nofollow noopener" target="_blank">#EchtVanNepOnderscheiden</a> <a href="https://infosec.exchange/tags/NepVersusEcht" class="mention hashtag" rel="nofollow noopener" target="_blank">#NepVersusEcht</a> <a href="https://infosec.exchange/tags/EchtVersusNep" class="mention hashtag" rel="nofollow noopener" target="_blank">#EchtVersusNep</a>

Erik van Straten<a href="https://noc.social/@hlindqvist" class="u-url mention" rel="nofollow noopener" target="_blank">@hlindqvist</a> : exactly.The Gl/C forum (*), which used to be called CA/B, was flawed from the start - because the *TARGET* group, internet users, had nothing to say.(*) Google/Chrome - with a couple of voiceless other parties to simulate a democratic process.<a href="https://infosec.exchange/tags/CABForum" class="mention hashtag" rel="nofollow noopener" target="_blank">#CABForum</a>

Erik van Straten<a href="https://gruene.social/@weddige" class="u-url mention" rel="nofollow noopener" target="_blank">@weddige</a> : sure!If you go to the centre of a city and see a building that obviously is a bank, then you don't need a "certificate" to be reasonably sure that it's a bank. You don't even have to know the exact address (that one could write as "nr.street.city.country").The building's geographical location and neighbourhood confirm the identity of what's written on the outside wall, because, in practice, the chance of it being fake is negligible.OTOH, if you were on holiday in some poor country, and for some reason you end up in a not-so-nice area, and near a scrapyard there's a building that *looks* like a bank; would you trust it?On the internet you often have no idea where a server is located and how trustworthy anyone with access to it is. The only thing you may know is its address (domain name) - without anyone reliably telling you who is currently "living at that address" (who is responsible for a webserver).https server certificates USED to do that - more or less.IMO the following things are needed:1) Browser users must be able to determine whether information, uniquely identifying the *owner* of a website, is available to them (apart from the address, i.e. the domain name). I.e. what type (DV or better) of certificate is being used;2) If better than DV, an indication of the *reliability* of the way in which the owner's identity was verified, must be shown. The overall reliability of a CSP (certificate service provider), as determined by the CAB-forum, may affect the reliability score of each certificate signed by that CSP (not as binary as it is/was, i.e. fully distrusting misbehaving CSP's);3) Users must be educated, at least via functionality built into browsers, that trust depends on answers to the following questions: a) How sure are you that a website owner is who they say they are (this info should be provided by the browser); b) What is the reputation of the owner (this knowledge is also required in real life, but IMO makes cert issuance too complicated; external alternative certifications such as ISO 9001 and 27001 *may* help); c) How trustworthy is the device and software that you use to browse; d) What is *your* risk (financial or otherwise) if anything goes wong because of some transaction.So I'm not saying that DV certificates should disappear, but that users should be able to distinguish between knowing just an address versus a website owner identity that was verified with high reliability, as well as a spectrum between those extremes.W.r.t. the killing of EV-certificates (by Google) based on one incident ("Stripe, Inc") and the assumption that "nobody checks certificates": that incident was caused by the fact that the visible identifying EV information was not worldwide unique (not even between US states) - which is a design error.Also, certificates contain way too much non-interesting information for end users (serial numbers, SAN's, public key etcetera). This must be fixed.Furthermore, wildcard certs and certs with lots if seemingly unrelated SAN's (*) in them should have lower reliability scores. If anyway possible, shared hosting should also decrease the reliability score.(*) Today I ran into one with 582 SAN's: <a href="https://crt.sh/?id=7293782180" rel="nofollow noopener" translate="no" target="_blank">https://crt.sh/?id=7293782180</a> - part of them are IDN's containing "characters" such as 📞, 😽, 💙 etcetera. This cert seems to have been used by a domain name parker, but the one with 📞, appears to be live now (with a certificate only for itself) : <a href="https://www.virustotal.com/gui/domain/vdiarybook-com.xn--3t8h.to/summary" rel="nofollow noopener" translate="no" target="_blank">https://www.virustotal.com/gui/domain/vdiarybook-com.xn--3t8h.to/summary</a> (see "Siblings").If end users are not provided with the minimum information required to reasonably assess their risks, or if most or all of them just don't (know how to) do that, then the internet is useless for medium to high-risk transactions. There will be too many victims of fraud (safety-nets are disappearing in NL) and too many company networks will get breached.<a href="https://infosec.exchange/tags/X" class="mention hashtag" rel="nofollow noopener" target="_blank">#X</a>.509 <a href="https://infosec.exchange/tags/x509certificates" class="mention hashtag" rel="nofollow noopener" target="_blank">#x509certificates</a> <a href="https://infosec.exchange/tags/Certificates" class="mention hashtag" rel="nofollow noopener" target="_blank">#Certificates</a> <a href="https://infosec.exchange/tags/Certificate" class="mention hashtag" rel="nofollow noopener" target="_blank">#Certificate</a> <a href="https://infosec.exchange/tags/DV" class="mention hashtag" rel="nofollow noopener" target="_blank">#DV</a> <a href="https://infosec.exchange/tags/OV" class="mention hashtag" rel="nofollow noopener" target="_blank">#OV</a> <a href="https://infosec.exchange/tags/EV" class="mention hashtag" rel="nofollow noopener" target="_blank">#EV</a> <a href="https://infosec.exchange/tags/QWAC" class="mention hashtag" rel="nofollow noopener" target="_blank">#QWAC</a> <a href="https://infosec.exchange/tags/CSP" class="mention hashtag" rel="nofollow noopener" target="_blank">#CSP</a> <a href="https://infosec.exchange/tags/CABforum" class="mention hashtag" rel="nofollow noopener" target="_blank">#CABforum</a> <a href="https://infosec.exchange/tags/Browser" class="mention hashtag" rel="nofollow noopener" target="_blank">#Browser</a> <a href="https://infosec.exchange/tags/Browsers" class="mention hashtag" rel="nofollow noopener" target="_blank">#Browsers</a> <a href="https://infosec.exchange/tags/Trust" class="mention hashtag" rel="nofollow noopener" target="_blank">#Trust</a> <a href="https://infosec.exchange/tags/Reliability" class="mention hashtag" rel="nofollow noopener" target="_blank">#Reliability</a> <a href="https://infosec.exchange/tags/Authentication" class="mention hashtag" rel="nofollow noopener" target="_blank">#Authentication</a> <a href="https://infosec.exchange/tags/Impersonation" class="mention hashtag" rel="nofollow noopener" target="_blank">#Impersonation</a> <a href="https://infosec.exchange/tags/CA" class="mention hashtag" rel="nofollow noopener" target="_blank">#CA</a>

Recent searches

Search options

Administered by:

Server stats:

#CABForum