-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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
TLS tests fail on Mac OS #35
Comments
Which requirements are not met? |
I believe:
We can consider issuing the certificate in the past to fix that last bit, so we don't have to constantly regenerate certificates. Or call the certificate generation script during test setup. |
Would this be much trouble? |
It requires having openssl (not just as a library) on the host running the tests, or adding another container to the test runs. So either require more host tooling - which I've avoided so far to simplify getting started as much as possible - or slow down tests a bit. If we do regenerate the certs, we should at least add some logic to ensure we only do so when they are expired, as certificate generation also takes a non-negligible amount of time. |
I see, then maybe issuing a cetificate in the past is not such a bad idea. However I'm also fine with adding more tooling on the host or into the container (probably the latter is better). Regarding only-when-expired check, that could probably be done with some lock file where we store the issue date (to avoid calling openssl on each run to check the issue date). |
Maybe, if we have a requirement on openssl anyway that shouldn't really be a meaningful overhead, though, unless we prevent starting a container altogether, which I don't think is trivial? |
I thought you meant having separate container for openssl:
In that case it would be a matter of running If we add openssl to the container with the test suite, then yeah, no difference ofcourse |
We will generate issues before July 1st, 2019 with the server name in the server name extension and not just CommonName. |
I suspect that there might be something else in play in addition to the aforementioned. This Certificate Transparency Policy might be important as well. The other doubts I have is how the exact DNS name of the server certificate should be composed and how Docker influences the flow. I provide a script bellow (assumes OpenSSL 1.1.1 or newer). By adjusting the system clock (safest bet + Mac command line openssl doesn't support the The Outcomes
Dates correct: Subject Alternative Name correct (assuming the DNS addresses make sense): The Key Usage and Extended Key Usage: The subject (issuer for self-signed): Public key algorithm and size: The Verifications Passes cert chain:
Passes cert verif, but with a warning: Optionally adding the certificate to the trusted ones in the Mac keychain doesn’t change much (expected since Docker): The Script Here is the certificate generation script:
|
Apparently Mac OS has very strict requirements for SSL certificates, which we do not meet with the certificates in our test suite: https://support.apple.com/en-us/103769
The text was updated successfully, but these errors were encountered: