I spent the last couple of hours trying to figure this out, but ASN.1 is pretty complicated and I haven't worked with it in depth before.
What I suspect is that the CSR is slightly malformed due to missing the field which would contain the set of certificate request attributes/extensions:
Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }}
From the man page for openssl req:
More precisely the Attributes in a PKCS#10 certificate request are defined as a SET OF Attribute . They are not OPTIONAL so if no attributes are present then they should be encoded as an empty SET OF . The invalid form does not include the empty SET OF whereas the correct form does.
An absence (empty set) of attributes should be denoted by a 0xA0 0x00 tag and length (or other compatible tags I guess), following the subject and subjectPKInfo in the certificate request.
Let's Encrypt's ASN.1 parser is erroring on the missing empty set of attributes, because (I believe) it is written in a way where the field is not optional. I think this is probably the correct behavior for a parser which strictly follows RFC2986.
ZeroSSL probably uses a different CSR parser which is not as strict.
I assume you are using some HSM software to generate this CSR. I would probably ask the vendor about this. If you can possibly include some kind of attribute/extension into the CSR (such as Subject Alternative Name), that would avoid the problem as well.
Hope that helps.