Issue title: OpenSSL allows the client to present X.509 certificates with malformed parameters in the signatureAlgorithm and signature fields.
 Issue body: ### Affected Versions
1.1.1g, 1.0.2u

### Setup
OpenSSL has been compiled from source in an alpine docker container. The following excerpt of the used docker file shows the build related commands:
```
RUN ./config --prefix=/build/ --openssldir=/build/ no-async 
RUN make -s && make install_sw -s
```
After building it the respective OpenSSL version and required libraries have been copied into an minimal docker container (from scratch).

The server is later started using the following command:
`openssl s_server -accept 4433 -Verify 100 -cert /cert/inputCerts/rootv3.pem -key /cert/keys/rootv3.pem -CAfile /cert/inputCerts/root.pem -verify_return_error`

All files mentioned in this report (certificates, keys, etc.) have been included in the attached zip archive.

### Issue
OpenSSL 1.1.1g and 1.0.2u allow the client to present an X.509 certificate in which the parameters in the signatureAlgorithm and signature fields match but are arbitrary byte strings (0xdeadbeef) rather than NULL as required by the specified signature algorithm.

### Reproduction
Connect to the started server using the following command:
` openssl s_client -connect localhost:4433 -cert ROOTv3_CAv3_LEAF_RSAv3_MalformedAlgorithmParameters__leaf_certificate1.pem -key rsakey_2.pem -CAfile ROOTv3_CAv3_LEAF_RSAv3_MalformedAlgorithmParameters__ca_certificate1.pem`

### Expected Result
Since the parameters are not conforming to the specification the certificate chain should be deemed invalid and rejected.

### Actual Result
OpenSSL happily accepts the certificate and proceeds with the handshake.

### Attachment
[opensslMalformedParameters.zip](https://github.com/openssl/openssl/files/4774578/opensslMalformedParameters.zip)

 Comments: 
 Comment 0: We do allow too much. But most of the times when we try to fix
some of those issues, real certificates break. Before any of those
issues are fixed I would like to see that at least one of the
linters (x509lint, cablint, zlint) has a check for that, so we can
see what the impact of such a change is.

 Comment 1: Maybe this means we need some capability flags so that these 'fixes' can be enabled/disabled ?
 Comment 2: This can wait until after 3.0, right?  All these issues about "too liberal in what we accept" are not important.
 Comment 3: So I've actually added a test to x509lint for that, and see real certificates that trigger the new checks, but it's a very low amount.
{'source': 'GithubIssues', 'repo_name_with_owner': 'openssl/openssl', 'issue_id': 638153101, 'repo_stars': 19782.0}