If we didn't walk the whole chain, then there may be any kind of errors in the
part of the chain we didn't check, so setting all flags looks like the safe
thing to do.
Fix a resource leak on windows platform, in mbedtls_x509_crt_parse_path,
in case a failure. when an error occurs, goto cleanup, and free the
resource, instead of returning error code immediately.
This commit changes the behaviour of mbedtls_ssl_parse_certificate
to make the two authentication modes SSL_VERIFY_REQUIRED and
SSL_VERIFY_OPTIONAL be in the following relationship:
Mode == SSL_VERIFY_REQUIRED
<=> Mode == SSL_VERIFY_OPTIONAL + check verify result
Also, it changes the behaviour to perform the certificate chain
verification even if the trusted CA chain is empty. Previously, the
function failed in this case, even when using optional verification,
which was brought up in #864.
This change fixes a regression introduced by an earlier commit that
modified x509_crt_verify_top() to ensure that valid certificates
that are after past or future valid in the chain are processed. However
the change introduced a change in behaviour that caused the
verification flags BADCERT_EXPIRED and BADCERT_FUTURE to always be set
whenever there is a failure in the verification regardless of the cause.
The fix maintains both behaviours:
* Ensure that valid certificates after future and past are verified
* Ensure that the correct verification flags are set.
To do so, a temporary pointer to the first future or past valid
certificate is maintained while traversing the chain. If a truly valid
certificate is found then that one is used, otherwise if no valid
certificate is found and the end of the chain is reached, the program
reverts back to using the future or past valid certificate.
Fix an issue that caused valid certificates being rejected whenever an
expired or not yet valid version of the trusted certificate was before the
valid version in the trusted certificate list.
Remove check on the pathLenConstraint value when looking for a parent to the
EE cert, as the constraint is on the number of intermediate certs below the
parent, and that number is always 0 at that point, so the constraint is always
satisfied.
The check was actually off-by-one, which caused valid chains to be rejected
under the following conditions:
- the parent certificate is not a trusted root, and
- it has pathLenConstraint == 0 (max_pathlen == 1 in our representation)
fixes#280
* mbedtls-1.3:
Use own implementation of strsep()
Add Changelog entries for this branch
Use symbolic constants in test data
Fixed pathlen contraint enforcement.
Additional corner cases for testing pathlen constrains. Just in case.
Added test case for pathlen constrains in intermediate certificates
If len is large enough, when cast to an int it will be negative and then the
test if( len > MAX_PATH - 3 ) will not behave as expected.
Ref: IOTSSL-518
backport of 261faed725
This helps in the case where an intermediate certificate is directly trusted.
In that case we want to ignore what comes after it in the chain, not only for
performance but also to avoid false negatives (eg an old root being no longer
trusted while the newer intermediate is directly trusted).
see #220
backport of fdbdd72
If the top certificate occurs twice in trust_ca (for example) it would
not be good for the second instance to be checked with check_path_cnt
reduced twice!
