Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"

404 views
Skip to first unread message

Ryan Dickson

unread,
Jan 16, 2026, 1:29:55 PMJan 16
to server...@groups.cabforum.org

Purpose of Ballot SC-097:

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all remaining use of SHA-1 signatures. 


Background: Over the years, various sunsets have limited the use of SHA-1 within the TLS BRs, including:

  • Ballot 118 (2014), which prevented the issuance of any new Subscriber certificates or Subordinate CA certificates using the SHA-1 signing algorithm.

  • SC-053 (2022), which prevented delegated OCSP signing using the SHA-1 signing algorithm.


Despite these sunsets, unexpired and unrevoked Subordinate CA certificates containing the SHA-1 signature algorithm still exist (examples). Additionally, Certificate Revocation List (CRL) Distribution Points disclosed to the CCADB are serving CRLs signed with SHA-1 (examples).


This ballot is motivated by discussion during the Server Certificate Working Group Meeting at Face-to-Face 66 (slide 11).


Scope: Update Section 7.1.3.2.1 to prohibit all remaining use of the SHA-1 signature algorithm from appearing in Certificates or status information responses. As part of this sunset and to promote cyber hygiene, all unexpired Subordinate CA certificates containing the SHA-1 signature algorithm must be revoked.


This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values, as currently required by RFC 5019.


Justification: This ballot complements prior efforts within the CA/Browser Forum to eliminate use of the SHA-1 signature algorithm from PKI hierarchies adhering to the TLS BRs.


Weaknesses regarding the use of the SHA-1 signature algorithm have been known for several years. These weaknesses were first demonstrated in 2017.


Benefits of adoption:

  • Promote cyber hygiene.

  • Reduce risk of potential collisions due to the inherent weaknesses of SHA-1, therefore improving security.

  • Promote use of modern PKI hierarchies.

  • Continuity with other technologies also looking to sunset use of SHA-1 (example).


Proposed Key Dates:


  • Effective September 15, 2026:

    • Prevent use of SHA-1 in new CRLs 

    • CAs must revoke unexpired Subordinate CA Certificates containing the SHA-1 signature algorithm.


Proposal Revision History:

  • Version #1 (created against TLS BR Version 2.1.9)

  • Version #2 (this version, created against TLS BR Version 2.2.1)


The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Clint Wilson (Apple) and Dimitris Zacharopoulos (HARICA).


— Motion Begins —


This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.1.


MODIFY the Baseline Requirements as specified in the following Redline:


https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54 


— Motion Ends —


This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:


Discussion (no less than 7 days)

  • Start: 2026-01-09 11:30:00 ET

  • End: 2026-01-16 13:29:59 ET


Vote for approval (7 days)

  • Start: 2026-01-16 13:30:00 ET

  • End: 2026-01-23 13:30:00 ET

Chris Clements

unread,
Jan 16, 2026, 1:34:37 PMJan 16
to server...@groups.cabforum.org
Google votes Yes on Ballot SC-097.

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O_WM1yVHKcyyTMrkFEr6dzTq3BaJRtbspVH6FthOmcO%3Dg%40mail.gmail.com.

Pedro FUENTES

unread,
Jan 16, 2026, 2:32:42 PMJan 16
to server...@groups.cabforum.org, server...@groups.cabforum.org
OISTE votes yes to SC-097

Le 16 janv. 2026 à 19:30, 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> a écrit :


--

Ben Wilson

unread,
Jan 19, 2026, 1:55:50 PMJan 19
to server...@groups.cabforum.org
Mozilla votes "yes" on Ballot SC-097.

--

Marco Schambach

unread,
Jan 20, 2026, 7:28:44 AMJan 20
to server...@groups.cabforum.org

IdenTrust votes “Yes” on SC-097

 

Marco S.

TrustID Program Manager

 

From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Friday, January 16, 2026 1:29 PM
To: server...@groups.cabforum.org
Subject: [External][Possible SPAM][Servercert-wg] Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"

 

Purpose of Ballot SC-097:

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all remaining use of SHA-1 signatures. 

 

Background: Over the years, various sunsets have limited the use of SHA-1 within the TLS BRs, including:

·  Ballot 118 (2014), which prevented the issuance of any new Subscriber certificates or Subordinate CA certificates using the SHA-1 signing algorithm.

·  SC-053 (2022), which prevented delegated OCSP signing using the SHA-1 signing algorithm.

 

Despite these sunsets, unexpired and unrevoked Subordinate CA certificates containing the SHA-1 signature algorithm still exist (examples). Additionally, Certificate Revocation List (CRL) Distribution Points disclosed to the CCADB are serving CRLs signed with SHA-1 (examples).

 

This ballot is motivated by discussion during the Server Certificate Working Group Meeting at Face-to-Face 66 (slide 11).

 

Scope: Update Section 7.1.3.2.1 to prohibit all remaining use of the SHA-1 signature algorithm from appearing in Certificates or status information responses. As part of this sunset and to promote cyber hygiene, all unexpired Subordinate CA certificates containing the SHA-1 signature algorithm must be revoked.

 

This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values, as currently required by RFC 5019.

 

Justification: This ballot complements prior efforts within the CA/Browser Forum to eliminate use of the SHA-1 signature algorithm from PKI hierarchies adhering to the TLS BRs.

 

Weaknesses regarding the use of the SHA-1 signature algorithm have been known for several years. These weaknesses were first demonstrated in 2017.

 

Benefits of adoption:

·  Promote cyber hygiene.

·  Reduce risk of potential collisions due to the inherent weaknesses of SHA-1, therefore improving security.

·  Promote use of modern PKI hierarchies.

·  Continuity with other technologies also looking to sunset use of SHA-1 (example).

 

Proposed Key Dates:

 

·  Effective September 15, 2026:

o Prevent use of SHA-1 in new CRLs 

o CAs must revoke unexpired Subordinate CA Certificates containing the SHA-1 signature algorithm.

 

Proposal Revision History:

·  Version #1 (created against TLS BR Version 2.1.9)

·  Version #2 (this version, created against TLS BR Version 2.2.1)

 

The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Clint Wilson (Apple) and Dimitris Zacharopoulos (HARICA).

 

— Motion Begins —

 

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.1.

 

MODIFY the Baseline Requirements as specified in the following Redline:

 

https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54 

 

— Motion Ends —

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

 

Discussion (no less than 7 days)

·  Start: 2026-01-09 11:30:00 ET

·  End: 2026-01-16 13:29:59 ET

 

Vote for approval (7 days)

·  Start: 2026-01-16 13:30:00 ET

·  End: 2026-01-23 13:30:00 ET

--

Backman, Antti

unread,
Jan 20, 2026, 8:08:52 AMJan 20
to server...@groups.cabforum.org
Telia votes ‘Yes’ on Ballot SC-097

//Antti

From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
--

蔡家宏(chtsai)

unread,
Jan 20, 2026, 7:15:57 PMJan 20
to server...@groups.cabforum.org

TWCA votes “YES”on Ballot SC-097

 

We will follow the proposal requirements and revoke the SHA1 Subordinate CA within the deadline.

 

 

 

Best Regards

 

蔡家宏 Chya-Hung Tsai

Director

Identification & Certificate Research
Tel: +886-2-2370-8886 ext. 722
Fax: +886-2-2388-6720
Email: cht...@twca.com.tw

10F., No. 85, Yanping South Road,

Taipei 100002, Taiwan(R.O.C.)
https://www.twca.com.tw

 

 

From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Saturday, January 17, 2026 2:29 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"

 

Purpose of Ballot SC-097:

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all remaining use of SHA-1 signatures. 

 

Background: Over the years, various sunsets have limited the use of SHA-1 within the TLS BRs, including:

·  Ballot 118 (2014), which prevented the issuance of any new Subscriber certificates or Subordinate CA certificates using the SHA-1 signing algorithm.

·  SC-053 (2022), which prevented delegated OCSP signing using the SHA-1 signing algorithm.

 

Despite these sunsets, unexpired and unrevoked Subordinate CA certificates containing the SHA-1 signature algorithm still exist (examples). Additionally, Certificate Revocation List (CRL) Distribution Points disclosed to the CCADB are serving CRLs signed with SHA-1 (examples).

 

This ballot is motivated by discussion during the Server Certificate Working Group Meeting at Face-to-Face 66 (slide 11).

 

Scope: Update Section 7.1.3.2.1 to prohibit all remaining use of the SHA-1 signature algorithm from appearing in Certificates or status information responses. As part of this sunset and to promote cyber hygiene, all unexpired Subordinate CA certificates containing the SHA-1 signature algorithm must be revoked.

 

This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values, as currently required by RFC 5019.

 

Justification: This ballot complements prior efforts within the CA/Browser Forum to eliminate use of the SHA-1 signature algorithm from PKI hierarchies adhering to the TLS BRs.

 

Weaknesses regarding the use of the SHA-1 signature algorithm have been known for several years. These weaknesses were first demonstrated in 2017.

 

Benefits of adoption:

·  Promote cyber hygiene.

·  Reduce risk of potential collisions due to the inherent weaknesses of SHA-1, therefore improving security.

·  Promote use of modern PKI hierarchies.

·  Continuity with other technologies also looking to sunset use of SHA-1 (example).

 

Proposed Key Dates:

 

·  Effective September 15, 2026:

o Prevent use of SHA-1 in new CRLs 

o CAs must revoke unexpired Subordinate CA Certificates containing the SHA-1 signature algorithm.

 

Proposal Revision History:

·  Version #1 (created against TLS BR Version 2.1.9)

·  Version #2 (this version, created against TLS BR Version 2.2.1)

 

The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Clint Wilson (Apple) and Dimitris Zacharopoulos (HARICA).

 

— Motion Begins —

 

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.1.

 

MODIFY the Baseline Requirements as specified in the following Redline:

 

https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54 

 

— Motion Ends —

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

 

Discussion (no less than 7 days)

·  Start: 2026-01-09 11:30:00 ET

·  End: 2026-01-16 13:29:59 ET

 

Vote for approval (7 days)

·  Start: 2026-01-16 13:30:00 ET

·  End: 2026-01-23 13:30:00 ET

--

jun....@cybertrust.co.jp

unread,
Jan 20, 2026, 7:56:04 PMJan 20
to server...@groups.cabforum.org
Cybertrust Japan votes "Yes" on SC-97.

-----Original Message-----
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Saturday, January 17, 2026 3:29 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"

Purpose of Ballot SC-097:

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all remaining use of SHA-1 signatures.




Background: Over the years, various sunsets have limited the use of SHA-1 within the TLS BRs, including:

* Ballot 118 <https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset-passed/> (2014), which prevented the issuance of any new Subscriber certificates or Subordinate CA certificates using the SHA-1 signing algorithm.

* SC-053 <https://cabforum.org/2022/01/26/ballot-sc053-sunset-for-sha-1-ocsp-signing/> (2022), which prevented delegated OCSP signing using the SHA-1 signing algorithm.




Despite these sunsets, unexpired and unrevoked Subordinate CA certificates containing the SHA-1 signature algorithm still exist (examples <https://docs.google.com/spreadsheets/d/1Fd6U_TB9TEGre_GTruHtaXDjTThqhvmvbX9y_bFFR7Q/edit?gid=76828475#gid=76828475> ). Additionally, Certificate Revocation List (CRL) Distribution Points disclosed to the CCADB are serving CRLs signed with SHA-1 (examples <https://docs.google.com/spreadsheets/d/1Fd6U_TB9TEGre_GTruHtaXDjTThqhvmvbX9y_bFFR7Q/edit?gid=1653596184#gid=1653596184> ).




This ballot is motivated by discussion during the Server Certificate Working Group Meeting at Face-to-Face 66 (slide 11 <https://drive.google.com/file/d/12QCFfLG6NvGFlnIwU_AVM5mD-tZ4hn89/view?usp=sharing> ).


Scope: Update Section 7.1.3.2.1 to prohibit all remaining use of the SHA-1 signature algorithm from appearing in Certificates or status information responses. As part of this sunset and to promote cyber hygiene, all unexpired Subordinate CA certificates containing the SHA-1 signature algorithm must be revoked.




This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values, as currently required by RFC 5019 <https://datatracker.ietf.org/doc/html/rfc5019> .


Justification: This ballot complements prior efforts within the CA/Browser Forum to eliminate use of the SHA-1 signature algorithm from PKI hierarchies adhering to the TLS BRs.


Weaknesses regarding the use of the SHA-1 signature algorithm have been known for several years. These weaknesses were first demonstrated <https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html> in 2017.




Benefits of adoption:

* Promote cyber hygiene.

* Reduce risk of potential collisions due to the inherent weaknesses of SHA-1, therefore improving security.

* Promote use of modern PKI hierarchies.

* Continuity with other technologies also looking to sunset use of SHA-1 (example <https://www.rfc-editor.org/info/rfc9905> ).




Proposed Key Dates:


* Effective September 15, 2026:

* Prevent use of SHA-1 in new CRLs

* CAs must revoke unexpired Subordinate CA Certificates containing the SHA-1 signature algorithm.


Proposal Revision History:

* Version #1 <https://github.com/cabforum/servercert/pull/635> (created against TLS BR Version 2.1.9)

* Version #2 <https://github.com/cabforum/servercert/pull/645> (this version, created against TLS BR Version 2.2.1)




The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Clint Wilson (Apple) and Dimitris Zacharopoulos (HARICA).




— Motion Begins —




This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.1.




MODIFY the Baseline Requirements as specified in the following Redline:




https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54 <https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54>




— Motion Ends —




This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:




Discussion (no less than 7 days)

* Start: 2026-01-09 11:30:00 ET

* End: 2026-01-16 13:29:59 ET




Vote for approval (7 days)

* Start: 2026-01-16 13:30:00 ET

* End: 2026-01-23 13:30:00 ET

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org <mailto:servercert-w...@groups.cabforum.org> .
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O_WM1yVHKcyyTMrkFEr6dzTq3BaJRtbspVH6FthOmcO%3Dg%40mail.gmail.com <https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O_WM1yVHKcyyTMrkFEr6dzTq3BaJRtbspVH6FthOmcO%3Dg%40mail.gmail.com?utm_medium=email&utm_source=footer> .

大野 文彰

unread,
Jan 21, 2026, 12:40:47 AMJan 21
to server...@groups.cabforum.org

SECOM Trust Systems votes YES on Ballot SC-097.

 

Best regards,

 

ONO Fumiaki / 大野 文彰

(Japanese name order: family name first, in uppercase)

SECOM Trust Systems CO., LTD.

 

From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Saturday, January 17, 2026 3:29 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"

 

Purpose of Ballot SC-097:

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all remaining use of SHA-1 signatures. 

 

Background: Over the years, various sunsets have limited the use of SHA-1 within the TLS BRs, including:

·  Ballot 118 (2014), which prevented the issuance of any new Subscriber certificates or Subordinate CA certificates using the SHA-1 signing algorithm.

·  SC-053 (2022), which prevented delegated OCSP signing using the SHA-1 signing algorithm.

 

Despite these sunsets, unexpired and unrevoked Subordinate CA certificates containing the SHA-1 signature algorithm still exist (examples). Additionally, Certificate Revocation List (CRL) Distribution Points disclosed to the CCADB are serving CRLs signed with SHA-1 (examples).

 

This ballot is motivated by discussion during the Server Certificate Working Group Meeting at Face-to-Face 66 (slide 11).

 

Scope: Update Section 7.1.3.2.1 to prohibit all remaining use of the SHA-1 signature algorithm from appearing in Certificates or status information responses. As part of this sunset and to promote cyber hygiene, all unexpired Subordinate CA certificates containing the SHA-1 signature algorithm must be revoked.

 

This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values, as currently required by RFC 5019.

 

Justification: This ballot complements prior efforts within the CA/Browser Forum to eliminate use of the SHA-1 signature algorithm from PKI hierarchies adhering to the TLS BRs.

 

Weaknesses regarding the use of the SHA-1 signature algorithm have been known for several years. These weaknesses were first demonstrated in 2017.

 

Benefits of adoption:

·  Promote cyber hygiene.

·  Reduce risk of potential collisions due to the inherent weaknesses of SHA-1, therefore improving security.

·  Promote use of modern PKI hierarchies.

·  Continuity with other technologies also looking to sunset use of SHA-1 (example).

 

Proposed Key Dates:

 

·  Effective September 15, 2026:

o Prevent use of SHA-1 in new CRLs 

o CAs must revoke unexpired Subordinate CA Certificates containing the SHA-1 signature algorithm.

 

Proposal Revision History:

·  Version #1 (created against TLS BR Version 2.1.9)

·  Version #2 (this version, created against TLS BR Version 2.2.1)

 

The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Clint Wilson (Apple) and Dimitris Zacharopoulos (HARICA).

 

— Motion Begins —

 

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.1.

 

MODIFY the Baseline Requirements as specified in the following Redline:

 

https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54 

 

— Motion Ends —

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

 

Discussion (no less than 7 days)

·  Start: 2026-01-09 11:30:00 ET

·  End: 2026-01-16 13:29:59 ET

 

Vote for approval (7 days)

·  Start: 2026-01-16 13:30:00 ET

·  End: 2026-01-23 13:30:00 ET

--

You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.

Nome Huang

unread,
Jan 21, 2026, 3:25:27 AMJan 21
to Server Certificate WG (CA/B Forum), ryand...@google.com
TrustAsia votes “YES” on Ballot SC-097.

Karina Sirota Goodley

unread,
Jan 21, 2026, 12:52:40 PM (14 days ago) Jan 21
to server...@groups.cabforum.org

Microsoft votes yes on ballot SC-097.

 

Best, Karina

 

From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

Sent: Friday, January 16, 2026 12:29 PM
To: server...@groups.cabforum.org

Subject: [EXTERNAL] [Servercert-wg] Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"

Purpose of Ballot SC-097:

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all remaining use of SHA-1 signatures. 

 

Background: Over the years, various sunsets have limited the use of SHA-1 within the TLS BRs, including:

?  Ballot 118 (2014), which prevented the issuance of any new Subscriber certificates or Subordinate CA certificates using the SHA-1 signing algorithm.

?  SC-053 (2022), which prevented delegated OCSP signing using the SHA-1 signing algorithm.

 

Despite these sunsets, unexpired and unrevoked Subordinate CA certificates containing the SHA-1 signature algorithm still exist (examples). Additionally, Certificate Revocation List (CRL) Distribution Points disclosed to the CCADB are serving CRLs signed with SHA-1 (examples).

 

This ballot is motivated by discussion during the Server Certificate Working Group Meeting at Face-to-Face 66 (slide 11).

 

Scope: Update Section 7.1.3.2.1 to prohibit all remaining use of the SHA-1 signature algorithm from appearing in Certificates or status information responses. As part of this sunset and to promote cyber hygiene, all unexpired Subordinate CA certificates containing the SHA-1 signature algorithm must be revoked.

 

This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values, as currently required by RFC 5019.

 

Justification: This ballot complements prior efforts within the CA/Browser Forum to eliminate use of the SHA-1 signature algorithm from PKI hierarchies adhering to the TLS BRs.

 

Weaknesses regarding the use of the SHA-1 signature algorithm have been known for several years. These weaknesses were first demonstrated in 2017.

 

Benefits of adoption:

?  Promote cyber hygiene.

?  Reduce risk of potential collisions due to the inherent weaknesses of SHA-1, therefore improving security.

?  Promote use of modern PKI hierarchies.

?  Continuity with other technologies also looking to sunset use of SHA-1 (example).

 

Proposed Key Dates:

 

?  Effective September 15, 2026:

o Prevent use of SHA-1 in new CRLs 

o CAs must revoke unexpired Subordinate CA Certificates containing the SHA-1 signature algorithm.

 

Proposal Revision History:

?  Version #1 (created against TLS BR Version 2.1.9)

?  Version #2 (this version, created against TLS BR Version 2.2.1)

 

The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Clint Wilson (Apple) and Dimitris Zacharopoulos (HARICA).

 

— Motion Begins —

 

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.1.

 

MODIFY the Baseline Requirements as specified in the following Redline:

 

https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54 

 

— Motion Ends —

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

 

Discussion (no less than 7 days)

?  Start: 2026-01-09 11:30:00 ET

?  End: 2026-01-16 13:29:59 ET

 

Vote for approval (7 days)

?  Start: 2026-01-16 13:30:00 ET

?  End: 2026-01-23 13:30:00 ET

Dustin Hollenback

unread,
Jan 21, 2026, 1:14:29 PM (14 days ago) Jan 21
to server...@groups.cabforum.org
Apple votes “Yes” on ballot SC-097.

Dimitris Zacharopoulos

unread,
Jan 21, 2026, 3:32:55 PM (14 days ago) Jan 21
to 'Ryan Dickson' via Server Certificate WG (CA/B Forum)
HARICA votes "yes" to ballot SC097.

Jan 16, 2026 19:29:59 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>:

--

성지은 Jieun Seong

unread,
Jan 21, 2026, 8:40:58 PM (13 days ago) Jan 21
to Ryan Dickson via Server Certificate WG (CA/B Forum)
MOIS votes YES on ballot SC-097.

Best regards,

Jieun Seong

Researcher / Dept of Digital Authentication

Korea Local Information Research & Development Institute, KLID

301, Seongam-ro, Mapo-gu, Seoul, 03923, Korea

D: +82 (2) 2031-9418 / M: +82 (10) 4800 0224

sji...@klid.or.kr / www.klid.or.kr


Date: 2026/01/17 03:30:01
From: "'Ryan Dickson' via Server Certificate WG (CA/B Forum)"
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"
--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O_WM1yVHKcyyTMrkFEr6dzTq3BaJRtbspVH6FthOmcO%3Dg%40mail.gmail.com.

Wayne Thayer

unread,
Jan 21, 2026, 10:56:40 PM (13 days ago) Jan 21
to server...@groups.cabforum.org
Fastly votes Yes on Ballot SC-097.

- Wayne

--

Michael Guenther

unread,
Jan 22, 2026, 4:17:39 AM (13 days ago) Jan 22
to server...@groups.cabforum.org
smime.p7m

Adriano Santoni

unread,
Jan 22, 2026, 4:20:02 AM (13 days ago) Jan 22
to server...@groups.cabforum.org

Actalis votes ‘Yes’ on Ballot SC-097

--Adriano


Il 16/01/2026 19:29, 'Ryan Dickson' via Server Certificate WG (CA/B Forum) ha scritto:
--

Scott Rea

unread,
Jan 22, 2026, 4:26:52 AM (13 days ago) Jan 22
to server...@groups.cabforum.org

eMudhra votes Yes on Ballot SC-097

On Jan 16, 2026, at 10:30 PM, 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:


--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O_WM1yVHKcyyTMrkFEr6dzTq3BaJRtbspVH6FthOmcO%3Dg%40mail.gmail.com.
Disclaimer: The email and its contents hold confidential information and are intended for the person or entity to which it is addressed. If you are not the intended recipient, please note that any distribution or copying of this email is strictly prohibited as per Company Policy, you are requested to notify the sender and delete the email and associated attachments with it from your system.

qi_ji...@itrus.com.cn

unread,
Jan 22, 2026, 4:51:37 AM (13 days ago) Jan 22
to servercert-wg
iTrusChina votes "Yes" on Ballot SC-097.

--

Yoshihiko Matsuo

unread,
Jan 22, 2026, 4:59:29 AM (13 days ago) Jan 22
to server...@groups.cabforum.org
JPRS votes YES on Ballot SC-97.

Yoshihiko Matsuo(JPRS)

On Fri, 16 Jan 2026 13:29:00 -0500
"'Ryan Dickson' via Server Certificate WG (CA/B Forum)" <server...@groups.cabforum.org> wrote:

> Purpose of Ballot SC-097:
>
> This ballot proposes updates to the Baseline Requirements for the Issuance
> and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to
> sunset all remaining use of SHA-1 signatures.
>
>
> Background: Over the years, various sunsets have limited the use of SHA-1
> within the TLS BRs, including:
>
> -
>
> Ballot 118
> <https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset-passed/>
> (2014), which prevented the issuance of any new Subscriber certificates
> or Subordinate CA certificates using the SHA-1 signing algorithm.
> -
>
> SC-053
> <https://cabforum.org/2022/01/26/ballot-sc053-sunset-for-sha-1-ocsp-signing/>
> (2022), which prevented delegated OCSP signing using the SHA-1 signing
> algorithm.
>
>
> Despite these sunsets, unexpired and unrevoked Subordinate CA certificates
> containing the SHA-1 signature algorithm still exist (examples
> <https://docs.google.com/spreadsheets/d/1Fd6U_TB9TEGre_GTruHtaXDjTThqhvmvbX9y_bFFR7Q/edit?gid=76828475#gid=76828475>).
> Additionally, Certificate Revocation List (CRL) Distribution Points
> disclosed to the CCADB are serving CRLs signed with SHA-1 (examples
> <https://docs.google.com/spreadsheets/d/1Fd6U_TB9TEGre_GTruHtaXDjTThqhvmvbX9y_bFFR7Q/edit?gid=1653596184#gid=1653596184>
> ).
>
>
> This ballot is motivated by discussion during the Server Certificate
> Working Group Meeting at Face-to-Face 66 (slide 11
> <https://drive.google.com/file/d/12QCFfLG6NvGFlnIwU_AVM5mD-tZ4hn89/view?usp=sharing>
> ).
>
> Scope: Update Section 7.1.3.2.1 to prohibit all remaining use of the SHA-1
> signature algorithm from appearing in Certificates or status information
> responses. As part of this sunset and to promote cyber hygiene, all
> unexpired Subordinate CA certificates containing the SHA-1 signature
> algorithm must be revoked.
>
>
> This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash
> or issuerNameHash values, as currently required by RFC 5019
> <https://datatracker.ietf.org/doc/html/rfc5019>.
>
> Justification: This ballot complements prior efforts within the CA/Browser
> Forum to eliminate use of the SHA-1 signature algorithm from PKI
> hierarchies adhering to the TLS BRs.
>
> Weaknesses regarding the use of the SHA-1 signature algorithm have been
> known for several years. These weaknesses were first demonstrated
> <https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html>
> in
> 2017.
>
>
> Benefits of adoption:
>
> -
>
> Promote cyber hygiene.
> -
>
> Reduce risk of potential collisions due to the inherent weaknesses of
> SHA-1, therefore improving security.
> -
>
> Promote use of modern PKI hierarchies.
> -
>
> Continuity with other technologies also looking to sunset use of SHA-1 (
> example <https://www.rfc-editor.org/info/rfc9905>).
>
>
> Proposed Key Dates:
>
>
> -
>
> Effective September 15, 2026:
> -
>
> Prevent use of SHA-1 in new CRLs
> -
>
> CAs must revoke unexpired Subordinate CA Certificates containing the
> SHA-1 signature algorithm.
>
>
> Proposal Revision History:
>
> -
>
> Version #1 <https://github.com/cabforum/servercert/pull/635> (created
> against TLS BR Version 2.1.9)
> -
>
> Version #2 <https://github.com/cabforum/servercert/pull/645> (this
> version, created against TLS BR Version 2.2.1)
>
>
> The following motion has been proposed by Ryan Dickson and Chris Clements
> of Google (Chrome Root Program) and endorsed by Clint Wilson (Apple) and
> Dimitris Zacharopoulos (HARICA).
>
>
> ? Motion Begins ?
>
>
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted TLS Server Certificates” (“Baseline
> Requirements”), based on Version 2.2.1.
>
>
> MODIFY the Baseline Requirements as specified in the following Redline:
>
>
> https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54
>
>
>
> ? Motion Ends ?
>
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
>
> Discussion (no less than 7 days)
>
> -
>
> Start: 2026-01-09 11:30:00 ET
> -
>
> End: 2026-01-16 13:29:59 ET
>
>
> Vote for approval (7 days)
>
> -
>
> Start: 2026-01-16 13:30:00 ET
> -
>
> End: 2026-01-23 13:30:00 ET
>

Entschew, Enrico

unread,
Jan 22, 2026, 7:01:21 AM (13 days ago) Jan 22
to server...@groups.cabforum.org

D-Trust votes „YES“ on Ballot SC-097.

 

Thanks,

Enrico

 

Von: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Gesendet: Freitag, 16. Januar 2026 19:29
An: server...@groups.cabforum.org
Betreff: [Servercert-wg] Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"

 

Purpose of Ballot SC-097:

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all remaining use of SHA-1 signatures. 

 

Background: Over the years, various sunsets have limited the use of SHA-1 within the TLS BRs, including:

· Ballot 118 (2014), which prevented the issuance of any new Subscriber certificates or Subordinate CA certificates using the SHA-1 signing algorithm.

· SC-053 (2022), which prevented delegated OCSP signing using the SHA-1 signing algorithm.

 

Despite these sunsets, unexpired and unrevoked Subordinate CA certificates containing the SHA-1 signature algorithm still exist (examples). Additionally, Certificate Revocation List (CRL) Distribution Points disclosed to the CCADB are serving CRLs signed with SHA-1 (examples).

 

This ballot is motivated by discussion during the Server Certificate Working Group Meeting at Face-to-Face 66 (slide 11).

 

Scope: Update Section 7.1.3.2.1 to prohibit all remaining use of the SHA-1 signature algorithm from appearing in Certificates or status information responses. As part of this sunset and to promote cyber hygiene, all unexpired Subordinate CA certificates containing the SHA-1 signature algorithm must be revoked.

 

This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values, as currently required by RFC 5019.

 

Justification: This ballot complements prior efforts within the CA/Browser Forum to eliminate use of the SHA-1 signature algorithm from PKI hierarchies adhering to the TLS BRs.

 

Weaknesses regarding the use of the SHA-1 signature algorithm have been known for several years. These weaknesses were first demonstrated in 2017.

 

Benefits of adoption:

· Promote cyber hygiene.

· Reduce risk of potential collisions due to the inherent weaknesses of SHA-1, therefore improving security.

· Promote use of modern PKI hierarchies.

· Continuity with other technologies also looking to sunset use of SHA-1 (example).

 

Proposed Key Dates:

 

· Effective September 15, 2026:

o Prevent use of SHA-1 in new CRLs 

o CAs must revoke unexpired Subordinate CA Certificates containing the SHA-1 signature algorithm.

 

Proposal Revision History:

· Version #1 (created against TLS BR Version 2.1.9)

· Version #2 (this version, created against TLS BR Version 2.2.1)

 

The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Clint Wilson (Apple) and Dimitris Zacharopoulos (HARICA).

 

— Motion Begins —

 

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.1.

 

MODIFY the Baseline Requirements as specified in the following Redline:

 

https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54 

 

— Motion Ends —

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

 

Discussion (no less than 7 days)

· Start: 2026-01-09 11:30:00 ET

· End: 2026-01-16 13:29:59 ET

 

Vote for approval (7 days)

· Start: 2026-01-16 13:30:00 ET

· End: 2026-01-23 13:30:00 ET

--

Josselin ALLEMANDOU

unread,
Jan 22, 2026, 8:10:29 AM (13 days ago) Jan 22
to server...@groups.cabforum.org

CERTIGNA votes « YES » on Ballot SC-097.

 

Josselin.

 

 

 

De : 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Envoyé : vendredi 16 janvier 2026 19:29
À : server...@groups.cabforum.org
Objet : [Servercert-wg] Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"

 

⚠ FR : Ce message provient de l'extérieur de l'organisation. N'ouvrez pas de liens ou de pièces jointes à moins que vous ne sachiez que le contenu est fiable.  ⚠

 

Purpose of Ballot SC-097:

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all remaining use of SHA-1 signatures. 

 

Background: Over the years, various sunsets have limited the use of SHA-1 within the TLS BRs, including:

·  Ballot 118 (2014), which prevented the issuance of any new Subscriber certificates or Subordinate CA certificates using the SHA-1 signing algorithm.

·  SC-053 (2022), which prevented delegated OCSP signing using the SHA-1 signing algorithm.

 

Despite these sunsets, unexpired and unrevoked Subordinate CA certificates containing the SHA-1 signature algorithm still exist (examples). Additionally, Certificate Revocation List (CRL) Distribution Points disclosed to the CCADB are serving CRLs signed with SHA-1 (examples).

 

This ballot is motivated by discussion during the Server Certificate Working Group Meeting at Face-to-Face 66 (slide 11).

 

Scope: Update Section 7.1.3.2.1 to prohibit all remaining use of the SHA-1 signature algorithm from appearing in Certificates or status information responses. As part of this sunset and to promote cyber hygiene, all unexpired Subordinate CA certificates containing the SHA-1 signature algorithm must be revoked.

 

This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values, as currently required by RFC 5019.

 

Justification: This ballot complements prior efforts within the CA/Browser Forum to eliminate use of the SHA-1 signature algorithm from PKI hierarchies adhering to the TLS BRs.

 

Weaknesses regarding the use of the SHA-1 signature algorithm have been known for several years. These weaknesses were first demonstrated in 2017.

 

Benefits of adoption:

·  Promote cyber hygiene.

·  Reduce risk of potential collisions due to the inherent weaknesses of SHA-1, therefore improving security.

·  Promote use of modern PKI hierarchies.

·  Continuity with other technologies also looking to sunset use of SHA-1 (example).

 

Proposed Key Dates:

 

·  Effective September 15, 2026:

o Prevent use of SHA-1 in new CRLs 

o CAs must revoke unexpired Subordinate CA Certificates containing the SHA-1 signature algorithm.

 

Proposal Revision History:

·  Version #1 (created against TLS BR Version 2.1.9)

·  Version #2 (this version, created against TLS BR Version 2.2.1)

 

The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Clint Wilson (Apple) and Dimitris Zacharopoulos (HARICA).

 

— Motion Begins —

 

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.1.

 

MODIFY the Baseline Requirements as specified in the following Redline:

 

https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54 

 

— Motion Ends —

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

 

Discussion (no less than 7 days)

·  Start: 2026-01-09 11:30:00 ET

·  End: 2026-01-16 13:29:59 ET

 

Vote for approval (7 days)

·  Start: 2026-01-16 13:30:00 ET

·  End: 2026-01-23 13:30:00 ET

--

Peter Miškovič

unread,
Jan 22, 2026, 9:57:56 AM (13 days ago) Jan 22
to server...@groups.cabforum.org

Disig votes „YES“ on Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs".

 

Regards

Peter Miskovic

 

From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: piatok 16. januára 2026 19:29
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"

 

Purpose of Ballot SC-097:

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all remaining use of SHA-1 signatures. 

 

Background: Over the years, various sunsets have limited the use of SHA-1 within the TLS BRs, including:

·     Ballot 118 (2014), which prevented the issuance of any new Subscriber certificates or Subordinate CA certificates using the SHA-1 signing algorithm.

·     SC-053 (2022), which prevented delegated OCSP signing using the SHA-1 signing algorithm.

 

Despite these sunsets, unexpired and unrevoked Subordinate CA certificates containing the SHA-1 signature algorithm still exist (examples). Additionally, Certificate Revocation List (CRL) Distribution Points disclosed to the CCADB are serving CRLs signed with SHA-1 (examples).

 

This ballot is motivated by discussion during the Server Certificate Working Group Meeting at Face-to-Face 66 (slide 11).

 

Scope: Update Section 7.1.3.2.1 to prohibit all remaining use of the SHA-1 signature algorithm from appearing in Certificates or status information responses. As part of this sunset and to promote cyber hygiene, all unexpired Subordinate CA certificates containing the SHA-1 signature algorithm must be revoked.

 

This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values, as currently required by RFC 5019.

 

Justification: This ballot complements prior efforts within the CA/Browser Forum to eliminate use of the SHA-1 signature algorithm from PKI hierarchies adhering to the TLS BRs.

 

Weaknesses regarding the use of the SHA-1 signature algorithm have been known for several years. These weaknesses were first demonstrated in 2017.

 

Benefits of adoption:

·     Promote cyber hygiene.

·     Reduce risk of potential collisions due to the inherent weaknesses of SHA-1, therefore improving security.

·     Promote use of modern PKI hierarchies.

·     Continuity with other technologies also looking to sunset use of SHA-1 (example).

 

Proposed Key Dates:

 

·     Effective September 15, 2026:

o   Prevent use of SHA-1 in new CRLs 

o   CAs must revoke unexpired Subordinate CA Certificates containing the SHA-1 signature algorithm.

 

Proposal Revision History:

·     Version #1 (created against TLS BR Version 2.1.9)

·     Version #2 (this version, created against TLS BR Version 2.2.1)

 

The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Clint Wilson (Apple) and Dimitris Zacharopoulos (HARICA).

 

— Motion Begins —

 

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.1.

 

MODIFY the Baseline Requirements as specified in the following Redline:

 

https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54 

 

— Motion Ends —

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

 

Discussion (no less than 7 days)

·     Start: 2026-01-09 11:30:00 ET

·     End: 2026-01-16 13:29:59 ET

 

Vote for approval (7 days)

·     Start: 2026-01-16 13:30:00 ET

·     End: 2026-01-23 13:30:00 ET

--

Kateryna Aleksieieva

unread,
Jan 23, 2026, 2:35:26 AM (12 days ago) Jan 23
to server...@groups.cabforum.org

Certum votes YES on Ballot SC-097

 

Kind regards,

Kateryna Aleksieieva

From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

Sent: Friday, January 16, 2026 7:29 PM
To: server...@groups.cabforum.org

Subject: [Servercert-wg] Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"

Purpose of Ballot SC-097:

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all remaining use of SHA-1 signatures. 

 

Background: Over the years, various sunsets have limited the use of SHA-1 within the TLS BRs, including:

· Ballot 118 (2014), which prevented the issuance of any new Subscriber certificates or Subordinate CA certificates using the SHA-1 signing algorithm.

· SC-053 (2022), which prevented delegated OCSP signing using the SHA-1 signing algorithm.

 

Despite these sunsets, unexpired and unrevoked Subordinate CA certificates containing the SHA-1 signature algorithm still exist (examples). Additionally, Certificate Revocation List (CRL) Distribution Points disclosed to the CCADB are serving CRLs signed with SHA-1 (examples).

 

This ballot is motivated by discussion during the Server Certificate Working Group Meeting at Face-to-Face 66 (slide 11).

 

Scope: Update Section 7.1.3.2.1 to prohibit all remaining use of the SHA-1 signature algorithm from appearing in Certificates or status information responses. As part of this sunset and to promote cyber hygiene, all unexpired Subordinate CA certificates containing the SHA-1 signature algorithm must be revoked.

 

This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values, as currently required by RFC 5019.

 

Justification: This ballot complements prior efforts within the CA/Browser Forum to eliminate use of the SHA-1 signature algorithm from PKI hierarchies adhering to the TLS BRs.

 

Weaknesses regarding the use of the SHA-1 signature algorithm have been known for several years. These weaknesses were first demonstrated in 2017.

 

Benefits of adoption:

· Promote cyber hygiene.

· Reduce risk of potential collisions due to the inherent weaknesses of SHA-1, therefore improving security.

· Promote use of modern PKI hierarchies.

· Continuity with other technologies also looking to sunset use of SHA-1 (example).

 

Proposed Key Dates:

 

· Effective September 15, 2026:

o Prevent use of SHA-1 in new CRLs 

o CAs must revoke unexpired Subordinate CA Certificates containing the SHA-1 signature algorithm.

 

Proposal Revision History:

· Version #1 (created against TLS BR Version 2.1.9)

· Version #2 (this version, created against TLS BR Version 2.2.1)

 

The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Clint Wilson (Apple) and Dimitris Zacharopoulos (HARICA).

 

— Motion Begins —

 

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.1.

 

MODIFY the Baseline Requirements as specified in the following Redline:

 

https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54 

 

— Motion Ends —

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

 

Discussion (no less than 7 days)

· Start: 2026-01-09 11:30:00 ET

· End: 2026-01-16 13:29:59 ET

 

Vote for approval (7 days)

· Start: 2026-01-16 13:30:00 ET

· End: 2026-01-23 13:30:00 ET

--

Alvin Wang

unread,
Jan 23, 2026, 2:59:31 AM (12 days ago) Jan 23
to Server Certificate WG (CA/B Forum), ryand...@google.com

SHECA votes "Yes" on Ballot SC-097


Best Regards

Alvin.Wang


On Saturday, January 17, 2026 at 2:29:55 AM UTC+8 ryand...@google.com wrote:

Tim Hollebeek

unread,
Jan 23, 2026, 10:40:03 AM (12 days ago) Jan 23
to server...@groups.cabforum.org
DigiCert votes YES on SC-097.

-Tim
From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Friday, January 16, 2026 1:29 PM

Subject: [Servercert-wg] Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"
 

Purpose of Ballot SC-097:

--

sde...@godaddy.com

unread,
Jan 23, 2026, 10:43:20 AM (12 days ago) Jan 23
to server...@groups.cabforum.org

GoDaddy votes Yes on Ballot SC-097.

 

Regards,

Steven

 

From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Friday, January 16, 2026 at 1:30 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"

Purpose of Ballot SC-097: This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all remaining use of SHA-1 signatures. Background: Over the years,

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

Purpose of Ballot SC-097:

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all remaining use of SHA-1 signatures. 

 

Background: Over the years, various sunsets have limited the use of SHA-1 within the TLS BRs, including:

·  Ballot 118 (2014), which prevented the issuance of any new Subscriber certificates or Subordinate CA certificates using the SHA-1 signing algorithm.

·  SC-053 (2022), which prevented delegated OCSP signing using the SHA-1 signing algorithm.

 

Despite these sunsets, unexpired and unrevoked Subordinate CA certificates containing the SHA-1 signature algorithm still exist (examples). Additionally, Certificate Revocation List (CRL) Distribution Points disclosed to the CCADB are serving CRLs signed with SHA-1 (examples).

 

This ballot is motivated by discussion during the Server Certificate Working Group Meeting at Face-to-Face 66 (slide 11).

 

Scope: Update Section 7.1.3.2.1 to prohibit all remaining use of the SHA-1 signature algorithm from appearing in Certificates or status information responses. As part of this sunset and to promote cyber hygiene, all unexpired Subordinate CA certificates containing the SHA-1 signature algorithm must be revoked.

 

This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values, as currently required by RFC 5019.

 

Justification: This ballot complements prior efforts within the CA/Browser Forum to eliminate use of the SHA-1 signature algorithm from PKI hierarchies adhering to the TLS BRs.

 

Weaknesses regarding the use of the SHA-1 signature algorithm have been known for several years. These weaknesses were first demonstrated in 2017.

 

Benefits of adoption:

·  Promote cyber hygiene.

·  Reduce risk of potential collisions due to the inherent weaknesses of SHA-1, therefore improving security.

·  Promote use of modern PKI hierarchies.

·  Continuity with other technologies also looking to sunset use of SHA-1 (example).

 

Proposed Key Dates:

 

·  Effective September 15, 2026:

o Prevent use of SHA-1 in new CRLs 

o CAs must revoke unexpired Subordinate CA Certificates containing the SHA-1 signature algorithm.

 

Proposal Revision History:

·  Version #1 (created against TLS BR Version 2.1.9)

·  Version #2 (this version, created against TLS BR Version 2.2.1)

 

The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Clint Wilson (Apple) and Dimitris Zacharopoulos (HARICA).

 

— Motion Begins —

 

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.1.

 

MODIFY the Baseline Requirements as specified in the following Redline:

 

https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54 

 

— Motion Ends —

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

 

Discussion (no less than 7 days)

·  Start: 2026-01-09 11:30:00 ET

·  End: 2026-01-16 13:29:59 ET

 

Vote for approval (7 days)

·  Start: 2026-01-16 13:30:00 ET

·  End: 2026-01-23 13:30:00 ET

Martijn Katerbarg

unread,
Jan 23, 2026, 10:46:39 AM (12 days ago) Jan 23
to server...@groups.cabforum.org
Sectigo votes YES to ballot SC-097

From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Friday, 16 January 2026 at 19:30
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"

This Message Is From an External Sender
This message came from outside your organization.

Purpose of Ballot SC-097:

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all remaining use of SHA-1 signatures. 


Background: Over the years, various sunsets have limited the use of SHA-1 within the TLS BRs, including:

  • Ballot 118 (2014), which prevented the issuance of any new Subscriber certificates or Subordinate CA certificates using the SHA-1 signing algorithm.

  • SC-053 (2022), which prevented delegated OCSP signing using the SHA-1 signing algorithm.


Despite these sunsets, unexpired and unrevoked Subordinate CA certificates containing the SHA-1 signature algorithm still exist (examples). Additionally, Certificate Revocation List (CRL) Distribution Points disclosed to the CCADB are serving CRLs signed with SHA-1 (examples).


This ballot is motivated by discussion during the Server Certificate Working Group Meeting at Face-to-Face 66 (slide 11).


Scope: Update Section 7.1.3.2.1 to prohibit all remaining use of the SHA-1 signature algorithm from appearing in Certificates or status information responses. As part of this sunset and to promote cyber hygiene, all unexpired Subordinate CA certificates containing the SHA-1 signature algorithm must be revoked.


This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values, as currently required by RFC 5019.


Justification: This ballot complements prior efforts within the CA/Browser Forum to eliminate use of the SHA-1 signature algorithm from PKI hierarchies adhering to the TLS BRs.


Weaknesses regarding the use of the SHA-1 signature algorithm have been known for several years. These weaknesses were first demonstrated in 2017.


Benefits of adoption:

  • Promote cyber hygiene.

  • Reduce risk of potential collisions due to the inherent weaknesses of SHA-1, therefore improving security.

  • Promote use of modern PKI hierarchies.

  • Continuity with other technologies also looking to sunset use of SHA-1 (example).


Proposed Key Dates:


  • Effective September 15, 2026:

    • Prevent use of SHA-1 in new CRLs 

    • CAs must revoke unexpired Subordinate CA Certificates containing the SHA-1 signature algorithm.


Proposal Revision History:

  • Version #1 (created against TLS BR Version 2.1.9)

  • Version #2 (this version, created against TLS BR Version 2.2.1)


The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Clint Wilson (Apple) and Dimitris Zacharopoulos (HARICA).


— Motion Begins —


This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.1.


MODIFY the Baseline Requirements as specified in the following Redline:


https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54 


— Motion Ends —


This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:


Discussion (no less than 7 days)

  • Start: 2026-01-09 11:30:00 ET

  • End: 2026-01-16 13:29:59 ET


Vote for approval (7 days)

  • Start: 2026-01-16 13:30:00 ET

  • End: 2026-01-23 13:30:00 ET

郭宗閔

unread,
Jan 23, 2026, 10:47:46 AM (12 days ago) Jan 23
to server...@groups.cabforum.org

Chunghwa Telecom votes Yes on Ballot SC-097.

 

Regards,

Tsung-Min Kuo

Chunghwa Telecom Co., Ltd.



本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

Janet Hines

unread,
Jan 23, 2026, 10:58:47 AM (12 days ago) Jan 23
to server...@groups.cabforum.org
VikingCloud votes YES on Ballot SC-097

From: 'Ryan Dickson' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Friday, January 16, 2026 at 1:30 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-097: "Sunset all remaining use of SHA-1 signatures in Certificates and CRLs"

Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


Purpose of Ballot SC-097:

This ballot proposes updates to the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (TLS BRs) to sunset all remaining use of SHA-1 signatures. 


Background: Over the years, various sunsets have limited the use of SHA-1 within the TLS BRs, including:

  • Ballot 118 (2014), which prevented the issuance of any new Subscriber certificates or Subordinate CA certificates using the SHA-1 signing algorithm.

  • SC-053 (2022), which prevented delegated OCSP signing using the SHA-1 signing algorithm.


Despite these sunsets, unexpired and unrevoked Subordinate CA certificates containing the SHA-1 signature algorithm still exist (examples). Additionally, Certificate Revocation List (CRL) Distribution Points disclosed to the CCADB are serving CRLs signed with SHA-1 (examples).


This ballot is motivated by discussion during the Server Certificate Working Group Meeting at Face-to-Face 66 (slide 11).


Scope: Update Section 7.1.3.2.1 to prohibit all remaining use of the SHA-1 signature algorithm from appearing in Certificates or status information responses. As part of this sunset and to promote cyber hygiene, all unexpired Subordinate CA certificates containing the SHA-1 signature algorithm must be revoked.


This proposal does not prohibit the use of SHA-1 to generate issuerKeyHash or issuerNameHash values, as currently required by RFC 5019.


Justification: This ballot complements prior efforts within the CA/Browser Forum to eliminate use of the SHA-1 signature algorithm from PKI hierarchies adhering to the TLS BRs.


Weaknesses regarding the use of the SHA-1 signature algorithm have been known for several years. These weaknesses were first demonstrated in 2017.


Benefits of adoption:

  • Promote cyber hygiene.

  • Reduce risk of potential collisions due to the inherent weaknesses of SHA-1, therefore improving security.

  • Promote use of modern PKI hierarchies.

  • Continuity with other technologies also looking to sunset use of SHA-1 (example).


Proposed Key Dates:


  • Effective September 15, 2026:

    • Prevent use of SHA-1 in new CRLs 

    • CAs must revoke unexpired Subordinate CA Certificates containing the SHA-1 signature algorithm.


Proposal Revision History:

  • Version #1 (created against TLS BR Version 2.1.9)

  • Version #2 (this version, created against TLS BR Version 2.2.1)


The following motion has been proposed by Ryan Dickson and Chris Clements of Google (Chrome Root Program) and endorsed by Clint Wilson (Apple) and Dimitris Zacharopoulos (HARICA).


— Motion Begins —


This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates” (“Baseline Requirements”), based on Version 2.2.1.


MODIFY the Baseline Requirements as specified in the following Redline:


https://github.com/cabforum/servercert/compare/86512c243874a62054b1cf4d0e7b424467e99a78..d02eb83c8153c2787d3567de382c759e0947af54 


— Motion Ends —


This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:


Discussion (no less than 7 days)

  • Start: 2026-01-09 11:30:00 ET

  • End: 2026-01-16 13:29:59 ET


Vote for approval (7 days)

  • Start: 2026-01-16 13:30:00 ET

  • End: 2026-01-23 13:30:00 ET

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/CADEW5O_WM1yVHKcyyTMrkFEr6dzTq3BaJRtbspVH6FthOmcO%3Dg%40mail.gmail.com.




Company Registration Details
VikingCloud is the registered business name of Sysxnet Limited. Sysxnet Limited is registered in Ireland under company registration number 147176 and its registered office is at 1st Floor, Block 71a, The Plaza, Park West Business Park, Dublin 12, Ireland.

Email Disclaimer
The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Sysxnet Limited is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt..

Tom Zermeno

unread,
Jan 23, 2026, 11:41:51 AM (12 days ago) Jan 23
to server...@groups.cabforum.org
SSL.com votes “Yes” on ballot SC-097.

Reply all
Reply to author
Forward
0 new messages