Skip to content

Conversation

@woodruffw
Copy link
Collaborator

WIP.

Signed-off-by: William Woodruff <[email protected]>
@alex
Copy link
Collaborator

alex commented Aug 1, 2024 via email

@github-actions
Copy link
Contributor

github-actions bot commented Aug 1, 2024

:shipit: No regressions found.

@woodruffw
Copy link
Collaborator Author

TIL, I'll look into using that (I did it the lazy way to start by just adapting the existing OpenSSL harness).

@woodruffw
Copy link
Collaborator Author

I might be missing it, but I don't see a newer validator in BoringSSL's X.509 APIs.

x509.h has this note:

// Legacy X.509 library.
//
// This header is part of OpenSSL's X.509 implementation. It is retained for
// compatibility but should not be used by new code. The functions are difficult
// to use correctly, and have buggy or non-standard behaviors. They are thus
// particularly prone to behavior changes and API removals, as BoringSSL
// iterates on these issues.
//
// In the future, a replacement library will be available. Meanwhile, minimize
// dependencies on this header where possible.

https://github.com/google/boringssl/blob/7a6e828dc53ba9a56bd49915f2a0780d63af97d2/include/openssl/x509.h#L95C1-L104C47

@alex
Copy link
Collaborator

alex commented Aug 2, 2024 via email

This harness uses BoringSSL's libpki instead,
which is markedly different from OpenSSL's
X.509 APIs.

Signed-off-by: William Woodruff <[email protected]>
@woodruffw
Copy link
Collaborator Author

This now uses libpki, although FWICT the libpki APIs don't perform SAN/name verification as part of path/chain building. I might be missing that in the CertificateVerifyOptions, so I'll spend some more time attempting to make this work in the coming days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants