apps/openssl.cnf default is to not enforce TLS. Should default to: enforce TLS

[ETERNALBLUEbullrun]

https://github.com/openssl/openssl/blob/master/apps/openssl.cnf#L345

ignore_keyusage = 1 # potentially needed quirk
unprotected_errors = 1 # potentially needed quirk

Lots of projects such as Termux ( termux/termux-packages#19208 ) use your defaults as-is,

which your manpages ( https://www.openssl.org/docs/man3.0/man1/openssl-cmp.html ) list as;

-unprotected_errors

    Accept missing or invalid protection of negative responses from the server. This applies to the following message types and contents:

        error messages

        negative certificate responses (IP/CP/KUP)

        negative revocation responses (RP)

        negative PKIConf messages

    WARNING: This setting leads to unspecified behavior and it is meant exclusively to allow interoperability with server implementations violating RFC 4210

[nhorman]

I'm not sure what the request here is @ETERNALBLUEbullrun . Reading the bug you referenced in termux, it seems they are shipping with the default configuration and assuming everything is 'ok'.

Is the ask to default those configuration settings to be off? I'm going to guess based on the comments by the configuration that cmp sets those on as a tradeoff between doing things correctly, and actually working with a large number of cmp servers in the wild.

@DDvO you created those entries back in 2020. Can you comment on their need, and weather or not we should continue to have them as defaults?

[DDvO]

This issue pretty clearly is a result of misinterpreting the semantics of the default OpenSSL config file.
The lines quoted above belong to a section holding a CMP configuration for using the Insta Demo CA, starting like this:

[insta] # CMP using Insta Demo CA

and has nothing to do with TLS.

Closing as invalid.

[ETERNALBLUEbullrun]

This issue pretty clearly is a result of misinterpreting the semantics of the default OpenSSL config file. The lines quoted above belong to a section holding a CMP configuration for using the Insta Demo CA, starting like this:

Insta is a common Certificate Authority. The issue is that the defaults should not accept "self-signed"/"missing" certificates. The [insta] header has #tls_use = 0 (not tls_use = 0) so presume this affects Insta cert's TLS.

The issue is a wish to default to

ignore_keyusage = 0
unprotected_errors = 0

plus, if this fails for lots of uses (test was just with Termux; does not fail with Termux,)
print messages to suggest to set those to 1 if the user has errors, suchas if(error) {printf("Configuration error: suggest you set openssl.cnf:ignore_keyusage = 1/n");}

[DDvO]

With your new text your issue makes somewhat more sense.

Yet still the two options mentioned have no relation with TLS. They only affect how the client handles CMP-level message protection, which may be missing or use a server cert for signing that is not allowed for signing data.

This example configuration does not use TLS for connecting to the Insta Demo CA.
Moreover, it is not meant for any productive use.

Anyway, maybe the two mentioned quirk options are no more needed for successfully running demo exchanges. In particular, the latter is mostly needed for handling strange behavior of EJBCA.
Did you try without them, with which results?

Please have a closer look at the documentation and revise your issue including its title.

[DDvO]

On a second thought, also having a look at termux/termux-packages#19208
I see quite some confusion on what the role of TLS is (or better: could be) in conjunction with CMP.

I'm going to extend the documentation and the example config file to make crystal clear that CMP is entirely independent of the message transfer and any transport-layer protection such as TLS.
This is something that should be clear from reading RFC 4210, RFC 8493, etc., but at least casual users seem to mix up the (options for) the CMP layer and the TLS layer. The latter can/should only serve as a second layer of defence regarding authentication and integrity, and it can add confidentiality (which is not really needed from the cert management perspective), if desired.

[ETERNALBLUEbullrun]

Am confused. Do these options just affect hosts? PKI is common, lots of clients use PKI with TLS;
https://www.rfc-editor.org/rfc/rfc4210 has

CMP
provides on-line interactions between PKI components, including an
exchange between a Certification Authority (CA) and a client system.

https://datatracker.ietf.org/doc/html/rfc9483 has

This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and transfer based on HTTP

Does the "undefined behaviour" from ignore_keyusage / unprotected_errors affect client SW (such as apt-get, yum, brew, Firefox or Outlook Express) or just hosts (such as Apache, Nginx or Abyss)?
[Termux has all of those except Outlook Express + Abyss]

[nhorman]

thank you @DDvO and @ETERNALBLUEbullrun for talking this one out

@DDvO given that you said you were going to extend the docs above, I'm assigning this one to you. Please let me know if that needs to change

[DDvO]

Am confused. Do these options just affect hosts? PKI is common, lots of clients use PKI with TLS; https://www.rfc-editor.org/rfc/rfc4210 has

CMP
provides on-line interactions between PKI components, including an
exchange between a Certification Authority (CA) and a client system.

https://datatracker.ietf.org/doc/html/rfc9483 has

This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and transfer based on HTTP

Does the "undefined behaviour" from ignore_keyusage / unprotected_errors affect client SW (such as apt-get, yum, brew, Firefox or Outlook Express) or just hosts (such as Apache, Nginx or Abyss)? [Termux has all of those except Outlook Express + Abyss]

@ETERNALBLUEbullrun, despite my above clarifying comments, you still mix up CMP and TLS.

CMP is an application-level protocol which is usually run over HTTP which may be tunneled over TLS,
but the CMP client options you believe to have trouble with have no effect on the OpenSSL use of TLS.
I added a respective comment to your erroneous bug report termux/termux-packages#19208.