The CA browser form agreed on a validity period of 825 days or less
(https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.3-redlined.pdf,
p4).
PR #1427 addressed that. However when an issuer signed/issued a certificate
with exactly 825 days, the check reported incorrectly that the life time
is too long.
This commit addressed that by adding a second to the calulation. Also the
output takes into account that it must be over ('>') 825 days, not '>='.
See #1070, kudos @poupas.
In addition it checks whether the first result was positive (in
terms of a finding). If so it does 4 rounds and checks the
result. So that other servers won't be penalized with 4 seconds.
derive-handshake-traffic-keys() uses the variables `derived_secret`, `server_write_key`, and `server_write_iv`, but they are not declared as local variables of the function. This PR fixes that.
to 1.1.0l and 1.1.1d. Seems that for the latter TLS 1.0 and 1.1
are disabled now, looking at the supported version extension.
However on the command line an s_client connect works. So
this commit need to be amended.
As noted in #1273, there are some environments that will not allow writing to /dev/stdout. PR #1277 was an attempt to address that problem (along with an unrelated problem), but it appears that work on #1277 has been abandoned.
At the moment, "/dev/stdout" is only used as a parameter to asciihex_to_binary_file (in fact, most calls to asciihex_to_binary_file specify "/dev/stdout" as the file parameter). This PR removes the file parameter from asciihex_to_binary_file (and so renames it asciihex_to_binary). In most cases, this just means removing "/dev/stdout" as a parameter to the function. In the few cases in which a parameter other than "/dev/stdout" was provided to asciihex_to_binary_file, this PR just uses a redirect (">" or ">>") to accomplish the same result as providing the output file to asciihex_to_binary_file().
Note that #1273 and #1277 raised the issue of trying to write to /tmp, and this PR does not attempt to address that.
This PR fixes two problems that occur when testing a server that supports TLSv1.3 using OpenSSL 1.1.1 in --ssl-native mode.
First, when testing whether the server has a cipher order, the value of $sclient_success is checked after each call to tls_sockets(), but $sclient_success. As the goal is just to verify that the connection was successful (and didn't downgrade), $? can be checked rather than $sclient_success. [When not in --ssl-native mode, this problem is masked since $sclient_success is set to 0 earlier in the function.]
The second problem is that line 6646 tries to copy "$TEMPDIR/$NODEIP.parse_tls13_serverhello.txt", but this file is currently only created (on line 6287) if tls_sockets() is used to determine the negotiated protocol. This PR fixes the problem by also populating "$TEMPDIR/$NODEIP.parse_tls13_serverhello.txt" when OpenSSL is used to determine the negotiated protocol.
The ciphersuites string for Safari 13.0 ends with a colon (':'). which causes OpenSSL to reject the command line when client simulation testing is performed in --ssl-native mode. This PR fixes the problem by removing the trailing colon.
As stated in #1435 when specifying ``-connect-timeout=20`` AND
``--parallel`` there asa problem with the file handles of child
processes (__testssl.sh: line 10454: 5: Bad file descriptor__).
This commit mitigates that in a sense that both switches can't
be used together. There's a check now in parse_cmd_line().
In addition it addresses a problem when fatal() is called and
e.g. JSON files haven't been created yet (error message ~
__testssl.sh: line 825: : No such file or directory__). It
introduces a global CMDLINE_PARSED which remembers the state
whether ``parse_cmd_line()`` has been fully executed or
not. Only when the former is the case it allows writing to files.
That implies that in main parse_cmd_line() has to be followed
by json_header() and similar.
According to MS this is the latest which is from July 2019.
This is the biggest CA store (probably a lot of intermediate
certificates in there).
This was pulled from MS as described in the Readme.md . It
is exactly the same whether CertUtil will be run from Windows 7
(almost: RIP) or Windows 10.
Other than before teh Java store was extracted directly from a keystore
from a Java JRE from https://jdk.java.net/.
The Debian keystore used previously used the certificates from the Debian
machine itself (installation script in ``/etc/ca-certificates/update.d/``.
Check with ``keytool -list -rfc -keystore /etc/ssl/certs/java/cacerts | grep -i 'alias'``
As a consequence this store contains less certificates:
etc/Java.pem:90
etc/Linux.pem:128
and needs some testing whether it really should be still included.
See #1429.
OpenBSD 6.6 had an offset with the HTTP header time of -3600 seconds.
This PR fixes that by adding the GMT time zone to parse_date()'s
HAS_FREEBSDDATE incarnation. That doesn't matter to FreeBSD.
Also now for older OpenBSDs the local and remote time are now
in the same format:
```
HTTP clock skew remote: Thu, 09 Jan 2020 12:52:32 GMT
local: Thu, 09 Jan 2020 12:52:02 GMT
``
so that a time difference is easier to spot.
Dirk Wetter
manuel
David Cooper