"CryptographyDeprecationWarning: Parsed a negative serial number, which is disallowed by RFC 5280"

[thbar]

Describe the bug

Things work as expected overall, but I get a warning, both on Mac Intel & Mac Silicon.

poetry run sslyze vagrant-$$REDACTED$$:443{192.168.33.14} --certinfo

/Users/thbar/Library/Caches/pypoetry/virtualenvs/ansible-REDACTED-py3.12/lib/python3.12/site-packages/sslyze/plugins/certificate_info/trust_stores/trust_store.py:55: CryptographyDeprecationWarning: Parsed a negative serial number, which is disallowed by RFC 5280. Loading this certificate will cause an exception in the next release of cryptography.
  self._x509_store = Store(load_pem_x509_certificates(self.path.read_text().encode("ascii")))

To Reproduce

It appears I have a reproduction with non-vagrant domains as well:

❯ poetry run sslyze www.google.fr --certinfo 

 CHECKING CONNECTIVITY TO SERVER(S)
 ----------------------------------

   www.google.fr:443         => 172.217.20.163 
/Users/thbar/Library/Caches/pypoetry/virtualenvs/ansible-REDACTED-py3.12/lib/python3.12/site-packages/sslyze/plugins/certificate_info/trust_stores/trust_store.py:55: CryptographyDeprecationWarning: Parsed a negative serial number, which is disallowed by RFC 5280. Loading this certificate will cause an exception in the next release of cryptography.
  self._x509_store = Store(load_pem_x509_certificates(self.path.read_text().encode("ascii")))

# SNIP

Expected behavior

Same output but without the warning.

Python environment (please complete the following information):

• OS: Mac OS Sonoma 14.5 (Silicon, but occurs on non-Silicon too)
• Python version: 3.12.2

Additional context

Happy to provide additional output if needed!

[janbrasna]

It was added here:

• Unable to load certificate with negative serial number pyca/cryptography#6609
  right away with a deprecation warning, at the same time with no clear deprecation path:/

Basically @pyca says "we don't like it so we're loud about it" but it was actually deemed correct to add that and keep it maintained (originally only "for some time" until all such certs get phased out, but it now seems there are some of these hardcoded in more root stores than originally thought, so I don't see them going away anytime soon…), what I don't like is the "Loading this certificate will cause an exception in the next release of cryptography" wording as no matter how I look at it, it's not true and should have been worded otherwise. Anyways it's going away at some point so it's good it raises warnings for now, to draw more attention to the issue…

More info:

• Negative serial numbers are mega deprecated pyca/cryptography#9897
• Possible to retain negative serial number parsing in x509 certificates ? pyca/cryptography#10247

So basically, yea, if there are no plans depending on cryptography beyond say v43 it's safe to ignore/silence this warning. Otherwise… plan accordingly;)

[Ricky-Tigg]

Hello. Same observavtion while executing sslyze --certinfo '[2607:f8b0:400a:807::2004]:443'.

[nabla-c0d3]

Hi ! I agree that this a problem, but there isn't much that SSLyze can do about it - it's up to pyca. I would argue that they shouldn't remove support for negative serial numbers as it will break a bunch of tools (including SSLyze) for (to me) no obvious win.

[ffloimair]

Agreed. One "problem" though is that this causes sslyze to return exit code 1 instead of 0. Can this be overriden somehow @nabla-c0d3 ?

I'm currently trying to update the sslyze homebrew formula and the test steps will fail the way it is now.

[janbrasna]

Oh! Right, a deprecation warning should not possibly exit with code:(

BTW, there's finally a plan on their side, i.e. timing / being blocked on MSFT, and changing the wording to better reflect the fact:

"Our tentative plan is to not remove support for negative serial parsing until after https://crt.sh/?q=28903A635B5280FAE6774C0B6DA7D6BAA64AF2E8 is removed from the MS trust store. We will update the warning to state that this will be removed in a future release."

— Originally posted by reaperhulk in pyca/cryptography#10247 (comment)