x509: certificate relies on legacy Common Name field, use SANs instead

[atc0005]

Overview

Recent versions of check_cert and lscert emit this error message when encountering certificates missing Subject Alternate Names (SANs) entries:

x509: certificate relies on legacy Common Name field, use SANs instead

As detailed by GH-70, Go deprecated support for using the Common Name field to verify hostnames when encountering an empty SANs list. Go 1.16 reiterated this deprecation and Go 1.17 removed the support.

This project switched to Go 1.17 for the v0.5.4 release in preparation for Go 1.16 going EOL in Q1 2022.

While restoring Common Name verification is technically possible, it's not a viable direction for this project. Instead, we should attempt to gracefully handle this scenario when encountered and provide useful feedback to the user so that they can best decide next steps to resolve the issue.

Workarounds:

• use binaries from the v0.5.3 release
• rebuild current codebase using Go 1.16

References

• x509: certificate relies on legacy Common Name field, use SANs or temporarily enable Common Name matching with GODEBUG=x509ignoreCN=0 #70
• https://go.dev/doc/go1.15#commonname
• https://go.dev/doc/go1.16#crypto/x509
• https://go.dev/doc/go1.17#crypto/x509
• https://chromestatus.com/feature/4981025180483584
• https://developers.google.com/web/updates/2017/03/chrome-58-deprecations#remove_support_for_commonname_matching_in_certificates
• https://frasertweedale.github.io/blog-redhat/posts/2017-07-11-cn-deprecation.html

[atc0005]

One potential workaround is to conditionally disable hostname verification (if requested) when the SANs list is empty. Perhaps something like, --disable-hostname-verification-if-empty-sans. The flag name is overly verbose, but pretty clear what the expected behavior should be.

[atc0005]

One potential workaround is to conditionally disable hostname verification (if requested) when the SANs list is empty. Perhaps something like, --disable-hostname-verification-if-empty-sans. The flag name is overly verbose, but pretty clear what the expected behavior should be.

Going with this option. It's not ideal, but it will work for now.

[atc0005]

While lscert is technically affected, it only doesn't "block" when encountering the error, just notes that it occurred. I currently consider this to be a desirable outcome when evaluating the certs for a specified system.

What may not be desirable is how/when the error is emitted. Will rely on further use of the tool and potential user feedback before making changes to that tool related to this GH issue.

[atc0005]

Fixed per #277.