'2 is not a valid CSR' when using again an ACME enabled Microsoft Certification Authority Web Enrollment Service

[michal-kuzak]

Hi,

We have a self managed Gitlab instance. Also we use an internal ACME Server.  After reconfiguring Gitlab according to these settings: https://docs.gitlab.com/omnibus/settings/ssl/#use-an-acme-server-other-than-lets-encrypt

our Acme Server https://github.com/grindsa/acme2certifier throw errors regarding the CSR Version: 

[Thu Sep 26 22:07:04.518566 2024] [wsgi:error] [pid 14:tid 139930579138112] [remote 172.18.0.5:55306] Order._finalize() ended
[Thu Sep 26 22:07:04.518498 2024] [wsgi:error] [pid 14:tid 139930579138112] [remote 172.18.0.5:55306] Certificate.enroll_and_store() ended with: None:urn:ietf:params:acme:error:badCSR
[Thu Sep 26 22:07:04.518531 2024] [wsgi:error] [pid 14:tid 139930579138112] [remote 172.18.0.5:55306] Order._csr_process() ended with order:kGhbW715JRaS 400:{urn:ietf:params:acme:error:badCSR:CSR validation failed
[Thu Sep 26 22:07:04.518455 2024] [wsgi:error] [pid 14:tid 139930579138112] [remote 172.18.0.5:55306] Certificate._csr_check() ended with False
[Thu Sep 26 22:07:04.518419 2024] [wsgi:error] [pid 14:tid 139930579138112] [remote 172.18.0.5:55306] Certificate._identifiers_load() ended with []
[Thu Sep 26 22:07:04.518375 2024] [wsgi:error] [pid 14:tid 139930579138112] [remote 172.18.0.5:55306] error: 2 is not a valid CSR version
[Thu Sep 26 22:07:04.518365 2024] [wsgi:error] [pid 14:tid 139930579138112] [remote 172.18.0.5:55306] Certificate._csr_check() error while checking csr.

I looked in the code and the following line has Version 2 set instead of 0.  /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/acme-client-2.0.18/lib/acme/client/certificate_request.rb:92

According to https://www.rfc-editor.org/rfc/rfc2986 this should be 0.

The components of type CertificationRequestInfo have the following meanings:

    version is the version number, for compatibility with future
      revisions of this document.  It shall be 0 for this version of
      the standard.

After I manually changed this, the ACME handshake did fully work, and the certs were created.  Is this by design or a compatibility issue ?

[michal-kuzak]

There was a request ..years ago to mimic what certbot did:

84

But this was a dependency bug in the certbot code and was later rectified. https://github.com/certbot/certbot/issues/9722

Current code uses '0' as per RFC

https://github.com/certbot/certbot/blob/main/acme/acme/crypto_util.py#L274

[unixcharles]

Hi Michal

I'm not totally clear why you are opening an issue here. It seem to me that you are referring to grindsa/acme2certifier which use the python client. This is the Ruby client.

I've never had this problem reported before. Have you experience this issue with the ruby client?

[michal-kuzak]

As mentioned in the ticket your ruby lib is used by gitlab (unless I'm reading this wrong) /opt/gitlab/embedded/lib/ruby/gems/3.1.0/gems/acme-client-2.0.18

The value doesn't conform to the RFC and also certbot fixed it. You have this in your code explicitly set. https://github.com/unixcharles/acme-client/blob/master/lib/acme/client/certificate_request.rb#L92

Sorry, not quite sure what more is needed here to proof.

P.S grindsa/acme2certifier is not a client, it's an ACME protocol compatible Server .. The CSR is created by the client and the ACME server just passes it the backend. In this case Microsoft Certification Authority Web Enrollment Service. The CSR request is created via the ruby lib.

[unixcharles]

OK, that make sense.

@will-in-wi, I know it's been years but do you remember why we settle on version 2 in https://github.com/unixcharles/acme-client/pull/85 ?