There were two rules that generated similar files, but with different
dates. Keep the one that's similar to md2 and md4.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
RFC5280 does not state that the `revocationDate` should be checked.
In addition, when no time source is available (i.e., when MBEDTLS_HAVE_TIME_DATE is not defined), `mbedtls_x509_time_is_past` always returns 0. This results in the CRL not being checked at all.
https://tools.ietf.org/html/rfc5280
Signed-off-by: Raoul Strackx <raoul.strackx@fortanix.com>
server2-sha256.crt had the issuer ON and CN encoded as UTF8String, but the
corresponding CA certificate test-ca_cat12.crt had them encoded as
PrintableString. The strings matched, which is sufficient according to RFC
5280 §7.1 and RFC 4518 §2.1. However, GnuTLS 3.4.10 requires the strings to
have the same encoding, so it did not accept that the
UTF8String "PolarSSL Test CA" certificate was signed by the
PrintableString "PolarSSL Test CA" CA.
Since Mbed TLS 2.14 (specifically ebc1f40aa0
merged via https://github.com/ARMmbed/mbedtls/pull/1641), server2-sha256.crt
is generated by Mbed TLS's own cert_write program, which emits a
PrintableString. In older versions, this file was generated by OpenSSL,
which started emitting UTF8String at some point.
4f928c0f37 merged via
https://github.com/ARMmbed/mbedtls/pull/2418 fixed this for the SHA-1
certificate which was used at the time. The present commit applies the same
fix for the SHA-256 certificate that is now in use.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
In the 2.7 branch, test-ca.crt has all the components of its Subject name
encoded as PrintableString, because it's generated with our cert_write
program, and our code writes all components that way until Mbed TLS 2.14.
But the default RSA SHA-256 certificate, server2-sha256.crt, has the O and CN
components of its Issuer name encoded as UTF8String, because it was generated
with OpenSSL and that's what OpenSSL does, regardless of how those components
were encoded in the CA's Subject name.
This triggers some overly strict behaviour in some libraries, most notably NSS
and GnuTLS (of interest to us in ssl-opt.sh) which won't recognize the trusted
root as a possible parent for the presented certificate, see for example:
https://github.com/ARMmbed/mbedtls/issues/1033
Fortunately, we have at our disposal a version of test-ca.crt with encodings
matching the ones in server2-sha256.crt, in the file test-ca_utf8.crt. So
let's append that to gnutls-cli's list of trusted roots, so that it recognizes
certs signed by this CA but with the O and CN components as UTF8String.
Note: Since https://github.com/ARMmbed/mbedtls/pull/1641 was merged (in Mbed
TLS 2.14), we changed how we encode those components, so in the 2.16 branch,
cert_write generates test-ca.crt with encodings that matches the ones used by
openssl when generating server2-sha256.crt, so the issue of gnutls-cli
rejecting server2-sha256.crt is specific to the 2.7 branch.
* restricted/pr/581:
Remove unnecessary empty line
Add a test for signing content with a long ECDSA key
Add documentation notes about the required size of the signature buffers
Add missing MBEDTLS_ECP_C dependencies in check_config.h
Change size of preallocated buffer for pk_sign() calls
Due to the way the current PK API works, it may have not been clear
for the library clients, how big output buffers they should pass
to the signing functions. Depending on the key type they depend on
MPI or EC specific compile-time constants.
Inside the library, there were places, where it was assumed that
the MPI size will always be enough, even for ECDSA signatures.
However, for very small sizes of the MBEDTLS_MPI_MAX_SIZE and
sufficiently large key, the EC signature could exceed the MPI size
and cause a stack overflow.
This test establishes both conditions -- small MPI size and the use
of a long ECDSA key -- and attempts to sign an arbitrary file.
This can cause a stack overvlow if the signature buffers are not
big enough, therefore the test is performed for an ASan build.
The relevant ASN.1 definitions for a PKCS#8 encoded Elliptic Curve key are:
PrivateKeyInfo ::= SEQUENCE {
version Version,
privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
privateKey PrivateKey,
attributes [0] IMPLICIT Attributes OPTIONAL
}
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
}
ECParameters ::= CHOICE {
namedCurve OBJECT IDENTIFIER
-- implicitCurve NULL
-- specifiedCurve SpecifiedECDomain
}
ECPrivateKey ::= SEQUENCE {
version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
privateKey OCTET STRING,
parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,
publicKey [1] BIT STRING OPTIONAL
}
Because of the two optional fields, there are 4 possible variants that need to
be parsed: no optional fields, only parameters, only public key, and both
optional fields. Previously mbedTLS was unable to parse keys with "only
parameters". Also, only "only public key" was tested. There was a test for "no
optional fields", but it was labelled incorrectly as SEC.1 and not run because
of a great renaming mixup.
Conflict resolution:
* ChangeLog
* tests/data_files/Makefile: concurrent additions, order irrelevant
* tests/data_files/test-ca.opensslconf: concurrent additions, order irrelevant
* tests/scripts/all.sh: one comment change conflicted with a code
addition. In addition some of the additions in the
iotssl-1381-x509-verify-refactor-restricted branch need support for
keep-going mode, this will be added in a subsequent commit.
The 'critical' boolean can be set to false in two ways:
- by leaving it implicit (test data generated by openssl)
- by explicitly setting it to false (generated by hand)
When a trusted CA is rolling its root keys, it could happen that for some
users the list of trusted roots contains two versions of the same CA with the
same name but different keys. Currently this is supported but wasn't tested.
Note: the intermediate file test-ca-alt.csr is commited on purpose, as not
commiting intermediate files causes make to regenerate files that we don't
want it to touch.
As we accept EE certs that are explicitly trusted (in the list of trusted
roots) and usually look for parent by subject, and in the future we might want
to avoid checking the self-signature on trusted certs, there could a risk that we
incorrectly accept a cert that looks like a trusted root except it doesn't
have the same key. This test ensures this will never happen.
The tests cover chains of length 0, 1 and 2, with one error, located at any of
the available levels in the chain. This exercises all three call sites of
f_vrfy (two in verify_top, one in verify_child). Chains of greater length
would not cover any new code path or behaviour that I can see.
We now have support for the entire SHA family to be used as
PRF in PKCS#5 v2.0, therefore we need to add new keys to test
these new functionalities.
This patch adds the new keys in `tests/data_files` and
commands to generate them in `tests/data_files/Makefile`.
Note that the pkcs8 command in OpenSSL 1.0 called with
the -v2 argument generates keys using PKCS#5 v2.0 with SHA1
as PRF by default.
(This behaviour has changed in OpenSSL 1.1, where the exact same
command instead uses PKCS#5 v2.0 with SHA256)
The new keys are generated by specifying different PRFs with
-v2prf.
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
Previously, 2048-bit and 4096-bit RSA key files had their bitsize indicated in their filename, while the original
1024-bit keys hadn't. This commit unifies the naming scheme by always indicating the bitsize in the filename.
This commit adds the commands used to generate the various RSA keys to tests/Makefile so that they can be easily
regenerated or modified, e.g. if larger key sizes or other encryption algorithms need to be tested in the future.
With SHA-1 deprecation, we need a few certificates using algorithms in
the default support list. Most tests still use SHA-1 though.
The generation process for the new certificates is recorded in the makefile.
