#cabforum — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #cabforum, aggregated by home.social.
-
@johan : je hebt een punt, maar de hele certificaten-industrie is ziek, webbrowsers zuigen en er bestaat veel te veel misleidende informatie (voorbeeld: zie plaatje met AI-bullshit - zie Alt voor info).
Er bestaan ook Europese certificaatuitgevers - wellicht minder voor DV-certificaten. Echter, met het CA/B-forum (de "toezichthouder" op certificaatuitgevers) bijna volledig in handen van US-organisaties zou Trump ook kunnen opdragen dat browsers alle certificaten van uitgevers in "vijandige" landen niet langer vertrouwen.
De supervisor van organisaties die domeinnamen verhuren is ook grotendeels Amerikaans.
Oftewel, autonomie wensen beperkt zich niet tot certificaten uitgegeven door Google en Let's Encrypt. Ons voorbereiden op worst-case scenario's lijkt mij zeer verstandig.
Overigens heb ik eerder een oplossing voorgesteld voor het phishing-probleem dat ik aankaartte, maar dat is kennelijk off-topic (ik sloeg aan op de kul dat certificaten iets met veilige websites te maken zouden hebben, een leugen die mensen al heel lang op het verkeerde been zet).
@wlaatje @wiert @wendyhk @publicspaces @FTM_nl
#GoogleIsEvil #BigTechIsEvil #USterroristCountry #DigitaleAutonomie #DVcertsAreEvil #CloudflareIsEvil #MitM #AitM #IETF #CABforum #WebBrowsers #Browsers #BeveiligdeWebSite
-
@johan : je hebt een punt, maar de hele certificaten-industrie is ziek, webbrowsers zuigen en er bestaat veel te veel misleidende informatie (voorbeeld: zie plaatje met AI-bullshit - zie Alt voor info).
Er bestaan ook Europese certificaatuitgevers - wellicht minder voor DV-certificaten. Echter, met het CA/B-forum (de "toezichthouder" op certificaatuitgevers) bijna volledig in handen van US-organisaties zou Trump ook kunnen opdragen dat browsers alle certificaten van uitgevers in "vijandige" landen niet langer vertrouwen.
De supervisor van organisaties die domeinnamen verhuren is ook grotendeels Amerikaans.
Oftewel, autonomie wensen beperkt zich niet tot certificaten uitgegeven door Google en Let's Encrypt. Ons voorbereiden op worst-case scenario's lijkt mij zeer verstandig.
Overigens heb ik eerder een oplossing voorgesteld voor het phishing-probleem dat ik aankaartte, maar dat is kennelijk off-topic (ik sloeg aan op de kul dat certificaten iets met veilige websites te maken zouden hebben, een leugen die mensen al heel lang op het verkeerde been zet).
@wlaatje @wiert @wendyhk @publicspaces @FTM_nl
#GoogleIsEvil #BigTechIsEvil #USterroristCountry #DigitaleAutonomie #DVcertsAreEvil #CloudflareIsEvil #MitM #AitM #IETF #CABforum #WebBrowsers #Browsers #BeveiligdeWebSite
-
@johan : je hebt een punt, maar de hele certificaten-industrie is ziek, webbrowsers zuigen en er bestaat veel te veel misleidende informatie (voorbeeld: zie plaatje met AI-bullshit - zie Alt voor info).
Er bestaan ook Europese certificaatuitgevers - wellicht minder voor DV-certificaten. Echter, met het CA/B-forum (de "toezichthouder" op certificaatuitgevers) bijna volledig in handen van US-organisaties zou Trump ook kunnen opdragen dat browsers alle certificaten van uitgevers in "vijandige" landen niet langer vertrouwen.
De supervisor van organisaties die domeinnamen verhuren is ook grotendeels Amerikaans.
Oftewel, autonomie wensen beperkt zich niet tot certificaten uitgegeven door Google en Let's Encrypt. Ons voorbereiden op worst-case scenario's lijkt mij zeer verstandig.
Overigens heb ik eerder een oplossing voorgesteld voor het phishing-probleem dat ik aankaartte, maar dat is kennelijk off-topic (ik sloeg aan op de kul dat certificaten iets met veilige websites te maken zouden hebben, een leugen die mensen al heel lang op het verkeerde been zet).
@wlaatje @wiert @wendyhk @publicspaces @FTM_nl
#GoogleIsEvil #BigTechIsEvil #USterroristCountry #DigitaleAutonomie #DVcertsAreEvil #CloudflareIsEvil #MitM #AitM #IETF #CABforum #WebBrowsers #Browsers #BeveiligdeWebSite
-
@johan : je hebt een punt, maar de hele certificaten-industrie is ziek, webbrowsers zuigen en er bestaat veel te veel misleidende informatie (voorbeeld: zie plaatje met AI-bullshit - zie Alt voor info).
Er bestaan ook Europese certificaatuitgevers - wellicht minder voor DV-certificaten. Echter, met het CA/B-forum (de "toezichthouder" op certificaatuitgevers) bijna volledig in handen van US-organisaties zou Trump ook kunnen opdragen dat browsers alle certificaten van uitgevers in "vijandige" landen niet langer vertrouwen.
De supervisor van organisaties die domeinnamen verhuren is ook grotendeels Amerikaans.
Oftewel, autonomie wensen beperkt zich niet tot certificaten uitgegeven door Google en Let's Encrypt. Ons voorbereiden op worst-case scenario's lijkt mij zeer verstandig.
Overigens heb ik eerder een oplossing voorgesteld voor het phishing-probleem dat ik aankaartte, maar dat is kennelijk off-topic (ik sloeg aan op de kul dat certificaten iets met veilige websites te maken zouden hebben, een leugen die mensen al heel lang op het verkeerde been zet).
@wlaatje @wiert @wendyhk @publicspaces @FTM_nl
#GoogleIsEvil #BigTechIsEvil #USterroristCountry #DigitaleAutonomie #DVcertsAreEvil #CloudflareIsEvil #MitM #AitM #IETF #CABforum #WebBrowsers #Browsers #BeveiligdeWebSite
-
Let's Encrypt 宣布证书有效期缩短到 45 天的计划。
- Let's Encrypt 用户可在 2026/5/13 起切换到签发有效期 45 天证书的 profile “tlsserver”。
- 2027/2/10 起，Let's Encrypt 默认签发证书有效期将从 90 天降至 64 天；2028/2/16 起降至 45 天。
- CA/B Forum 正研究 dns-persist-01 验证方式，使证书更新不再需要修改 DNS 记录；预计 2026 年可供使用。
https://letsencrypt.org/2025/12/02/from-90-to-45.html
thread: /4701
#CABForum #PKI #LetsEncrypt
Telegram 原文 -
I totally missed the memo that #letsencrypt disabled #OCSP:
https://letsencrypt.org/2024/12/05/ending-ocsp
And I see that there has been a #cabforum ballot making OCSP optional with only one issuer opposing:
A terrible Idea. And to make it worst, LE is distributing their #CRL over #cloudflare just as they did with their OCSP endpoints.
-
I totally missed the memo that #letsencrypt disabled #OCSP:
https://letsencrypt.org/2024/12/05/ending-ocsp
And I see that there has been a #cabforum ballot making OCSP optional with only one issuer opposing:
A terrible Idea. And to make it worst, LE is distributing their #CRL over #cloudflare just as they did with their OCSP endpoints.
-
I totally missed the memo that #letsencrypt disabled #OCSP:
https://letsencrypt.org/2024/12/05/ending-ocsp
And I see that there has been a #cabforum ballot making OCSP optional with only one issuer opposing:
A terrible Idea. And to make it worst, LE is distributing their #CRL over #cloudflare just as they did with their OCSP endpoints.
-
I totally missed the memo that #letsencrypt disabled #OCSP:
https://letsencrypt.org/2024/12/05/ending-ocsp
And I see that there has been a #cabforum ballot making OCSP optional with only one issuer opposing:
A terrible Idea. And to make it worst, LE is distributing their #CRL over #cloudflare just as they did with their OCSP endpoints.
-
Does anyone know of the CA/Browser forum SC81 ballot to reduce certificate validity periods only applies to TLS Server and Client certificate usages or if it applies to all key usages?
This could create a huge pile of churn and toil if it also applies to certs used for SAML assertion signing, which have key usages set for: Digital Signature, Non Repudiation, Key and Data Encipherment.
ETA: paging @ScottHelme now that I've found him here.
-
Does anyone know of the CA/Browser forum SC81 ballot to reduce certificate validity periods only applies to TLS Server and Client certificate usages or if it applies to all key usages?
This could create a huge pile of churn and toil if it also applies to certs used for SAML assertion signing, which have key usages set for: Digital Signature, Non Repudiation, Key and Data Encipherment.
ETA: paging @ScottHelme now that I've found him here.
-
Does anyone know of the CA/Browser forum SC81 ballot to reduce certificate validity periods only applies to TLS Server and Client certificate usages or if it applies to all key usages?
This could create a huge pile of churn and toil if it also applies to certs used for SAML assertion signing, which have key usages set for: Digital Signature, Non Repudiation, Key and Data Encipherment.
ETA: paging @ScottHelme now that I've found him here.
-
Does anyone know of the CA/Browser forum SC81 ballot to reduce certificate validity periods only applies to TLS Server and Client certificate usages or if it applies to all key usages?
This could create a huge pile of churn and toil if it also applies to certs used for SAML assertion signing, which have key usages set for: Digital Signature, Non Repudiation, Key and Data Encipherment.
ETA: paging @ScottHelme now that I've found him here.
-
Does anyone know of the CA/Browser forum SC81 ballot to reduce certificate validity periods only applies to TLS Server and Client certificate usages or if it applies to all key usages?
This could create a huge pile of churn and toil if it also applies to certs used for SAML assertion signing, which have key usages set for: Digital Signature, Non Repudiation, Key and Data Encipherment.
ETA: paging @ScottHelme now that I've found him here.
-
CA/B Forum 投票通过 SC-081v3。新提案的内容之一是将公共 TLS 证书有效期缩短到 47 天。
根据提案，在 2026、2027 和 2029 年的 3 月 15 日，证书的最长有效期将被缩短到 200 天、100 天和 47 天。 [1]
groups.google.com/~
1. github.com/~
thread: /4610
linksrc: https://t.me/bupt_moe/2403
#CABForum #PKI
Telegram 原文 -
Apple 提议在最晚 2027 年末将 TLS 证书有效期从 398 日降为 45 日。
PR 发布者 Clint Wilson 为 Apple 在 CA/B 论坛的代表。
https://github.com/cabforum/servercert/pull/553
#CABForum #TLS #Apple
Telegram 原文 -
Apple Enrages IT — 45-Day Cert Expiration Fury – Source: securityboulevard.com https://ciso2ciso.com/apple-enrages-it-45-day-cert-expiration-fury-source-securityboulevard-com/ #SecurityChallengesandOpportunitiesofRemoteWork #DeepFakeandOtherSocialEngineeringTactics #CertificateandKeyLifecycleManagement #90-dayTLScertificatevalidity #CertificateandKeyManagement #IdentityandAccessManagement #SecurityBoulevard(Original) #rssfeedpostgeneratorecho #CertificateAutomation #ApplicationSecurity #CABForum
-
Apple Enrages IT — 45-Day Cert Expiration Fury – Source: securityboulevard.com https://ciso2ciso.com/apple-enrages-it-45-day-cert-expiration-fury-source-securityboulevard-com/ #SecurityChallengesandOpportunitiesofRemoteWork #DeepFakeandOtherSocialEngineeringTactics #CertificateandKeyLifecycleManagement #90-dayTLScertificatevalidity #CertificateandKeyManagement #IdentityandAccessManagement #SecurityBoulevard(Original) #rssfeedpostgeneratorecho #CertificateAutomation #ApplicationSecurity #CABForum
-
Apple Enrages IT — 45-Day Cert Expiration Fury – Source: securityboulevard.com https://ciso2ciso.com/apple-enrages-it-45-day-cert-expiration-fury-source-securityboulevard-com/ #SecurityChallengesandOpportunitiesofRemoteWork #DeepFakeandOtherSocialEngineeringTactics #CertificateandKeyLifecycleManagement #90-dayTLScertificatevalidity #CertificateandKeyManagement #IdentityandAccessManagement #SecurityBoulevard(Original) #rssfeedpostgeneratorecho #CertificateAutomation #ApplicationSecurity #CABForum
-
I 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. #cabforum #certificates https://github.com/cabforum/servercert/pull/553
-
I 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. #cabforum #certificates https://github.com/cabforum/servercert/pull/553
-
I 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. #cabforum #certificates https://github.com/cabforum/servercert/pull/553
-
I 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. #cabforum #certificates https://github.com/cabforum/servercert/pull/553
-
I 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. #cabforum #certificates https://github.com/cabforum/servercert/pull/553
-
for 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
"
https://github.com/cabforum/servercert/pull/553
#tls #cabforum -
for 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
"
https://github.com/cabforum/servercert/pull/553
#tls #cabforum -
for 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
"
https://github.com/cabforum/servercert/pull/553
#tls #cabforum -
for 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
"
https://github.com/cabforum/servercert/pull/553
#tls #cabforum -
Not seen this mentioned here yet from any of my usuals.
Court issues TRO on digicert revoking certs as required by CA/BF.
https://www.courtlistener.com/docket/68995396/alegeus-technologies-llc-v-digicert/
Popcorn at the ready.
-
Not seen this mentioned here yet from any of my usuals.
Court issues TRO on digicert revoking certs as required by CA/BF.
https://www.courtlistener.com/docket/68995396/alegeus-technologies-llc-v-digicert/
Popcorn at the ready.
-
Not seen this mentioned here yet from any of my usuals.
Court issues TRO on digicert revoking certs as required by CA/BF.
https://www.courtlistener.com/docket/68995396/alegeus-technologies-llc-v-digicert/
Popcorn at the ready.
-
Not seen this mentioned here yet from any of my usuals.
Court issues TRO on digicert revoking certs as required by CA/BF.
https://www.courtlistener.com/docket/68995396/alegeus-technologies-llc-v-digicert/
Popcorn at the ready.
