Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Certs signed with the SHA-1 hash function #219

Closed
atc0005 opened this issue Aug 18, 2021 · 5 comments
Closed

Certs signed with the SHA-1 hash function #219

atc0005 opened this issue Aug 18, 2021 · 5 comments
Assignees
@atc0005
Labels
config hash question Further information is requested signature
Milestone
v0.25.3

Comments

@atc0005
Copy link
Owner

atc0005 commented Aug 18, 2021 •
edited
Loading

From the Go 1.17 release notes:

Beginning in the next release, Go 1.18, crypto/x509 will reject certificates signed with the SHA-1 hash function. This doesn't apply to self-signed root certificates. Practical attacks against SHA-1 have been demonstrated in 2017 and publicly trusted Certificate Authorities have not issued SHA-1 certificates since 2015.

There are older certs that I have seen signed with the MD5 hash which were exposed with thecertsum tool. If those certs are still supported, then we will likely need to support SHA-1 certs too.
@atc0005 atc0005 added this to the Future milestone Aug 18, 2021
@atc0005 atc0005 self-assigned this Aug 18, 2021
@atc0005
Copy link
Owner Author

atc0005 commented Mar 15, 2022

From https://go.dev/doc/go1.18#sha1:

Rejecting SHA-1 certificates

crypto/x509 will now reject certificates signed with the SHA-1 hash function. This doesn't apply to self-signed root certificates. Practical attacks against SHA-1 have been demonstrated since 2017 and publicly trusted Certificate Authorities have not issued SHA-1 certificates since 2015.

This can be temporarily reverted by setting the GODEBUG=x509sha1=1 environment variable. This option will be removed in Go 1.19.

@atc0005
Copy link
Owner Author

atc0005 commented May 25, 2022

Potential relevant spot in the code to extend:

check-cert/internal/certs/certs.go

Lines 448 to 450 in f61c152

// Handle MD5 signature verification ourselves since Go considers
// the MD5 algorithm to be insecure (rightly so).
if cert.SignatureAlgorithm == x509.MD5WithRSA {

@atc0005 atc0005 added the question Further information is requested label May 25, 2022
@atc0005
Copy link
Owner Author

atc0005 commented Nov 19, 2024 •
edited
Loading

Looks like this is picking up steam (activity today):

@atc0005 atc0005 modified the milestones: Future, v0.26.0 Dec 14, 2024
@atc0005
Copy link
Owner Author

atc0005 commented Dec 14, 2024

This may already be handled by recent refactoring work. Adding to next milestone as a reminder to double check.

@atc0005 atc0005 modified the milestones: v0.26.0, v0.25.3 Dec 16, 2024
@atc0005
Copy link
Owner Author

atc0005 commented Dec 16, 2024

Considering this resolved per the work here:

@atc0005 atc0005 closed this as completed Dec 16, 2024
atc0005 added a commit that referenced this issue Dec 18, 2024
@atc0005
Initial implementation of chain order validation
485ca30 
OVERVIEW

This set of changes applies to both the `check_cert` plugin and the
`lscert` CLI tool. While the primary focus is adding a prototype
implementation of "chain order" validation logic, other ergonomic and
display changes have been applied to the `lscert` tool. Some of those
changes are likely to be refined further in near future releases as
additional validation checks are applied.

CHANGES

- update `check_cert` plugin
  - add new `Chain Order` validation type
    - assert that leaf certificate is first in chain, followed by the
      intermediate which signed it, a potential second intermediate
      which signed the former and so on
    - current implementation objects to a single leaf cert in a chain,
      though this behavior may be moved to a separate validation check
      specific to intermediates
    - current implementation notes the presence of a root certificate
      and cautions that some platforms will object to this, though
      this behavior may be moved to a separate validation check in the
      future
    - offers advice for replacing a certificate chain when specific CA
      vendors are matched
      - currently only Sectigo/InCommon is supported, though the plan
        is to support multiple CAs once further feedback is gathered
  - add new performance data metrics
    - `certs_ordered`
    - `certs_misordered`
  - extend tests to cover new validation type
- update `lscert`
  - incorporate new validation check
  - rework summary display to use emoji status indicators
    (pass/neutral/warn/crit)
  - rename headers to emphasize "cert chain" over just "certs"
  - incorporate the same "advice" output that the `check_cert` plugin
    now emits for `Chain Order` validation problems

CREDIT

The following LLM sources were used for inspiration or starting code
samples for some of the included changes:

- ChatGPT, OpenAI
- Google Gemini
- Claude (Anthropic AI assistant)

In particular, I used all of these sources for assistance with logic
for certificate chain ordering, signature validation and misc other
tasks. While none provided solutions I could use as-is, all were
helpful in pointing me in the right direction when I needed it.

REFERENCES

- GH-1004
- GH-364
- GH-365
- GH-219
@atc0005 atc0005 mentioned this issue Dec 18, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@atc0005 atc0005

Labels
config hash question Further information is requested signature
Projects
None yet
Milestone
v0.25.3
Development

No branches or pull requests
1 participant
@atc0005