glatzert / ACME-Server-ADCS

I was testing with acme.sh and noticed there is an error caused by acmesh-official/acme.sh#1335, acmesh-official/acme.sh@f8ca6d9.

Due to acme.sh adding the extendedKeyUsage extension to the automatically generated CSR, the CsrValidator.cs SubjectAlternateNamesAreValid function returns false since x509Ext.ObjectId.Name is now equal to XCN_OID_ENHANCED_KEY_USAGE first.

ACME-Server-ADCS/src/ACME.CertProvider.ADCS/CsrValidator.cs

Line 88 in 3b45df3

    
           if (x509Ext.ObjectId.Name != CertEnroll.CERTENROLL_OBJECTID.XCN_OID_SUBJECT_ALT_NAME2)

Removing extendedKeyUsage=serverAuth,clientAuth from the acme.sh script (part that generates the CSR file) fixes the issue. Not sure if this needs to be addressed here or with acme.sh.

[Thu 06 Apr 2023 04:50:20 AM UTC] Sign error, wrong status
[Thu 06 Apr 2023 04:50:20 AM UTC] {"status":"invalid","identifiers":[{"type":"dns","value":"test.example.local"}],"error":{"type":"urn:ietf:params:acme:error:badCSR","detail":"SAN Invalid."},"authorizations":["https://caissueadcs.example.local/order/RqaBOEM7pUG0wnxYNc_INg/auth/Cpi4l4UtRkCiiJaoTd5nFA"],"finalize":"https://acme.example.local/order/RqaBOEM7pUG0wnxYNc_INg/finalize"}

I'll fix it in the server.
It's a oversight of me to not allow other extensions besides SAN.

Most likely fixed in V1.0.3 (I did not run tests yet)

@glatzert V1.0.3 fixed the issue

acme.sh badCSR SAN Invalid Error