bruncsak

Hi @felixfontein, Thanks for the info, it is really useful! So, at the end, is there any plan to make pebble conform to RFC8555 in that respect, or will it...

Sorry, I do not want to enter into debate on that, but the behavior is different between pebble and letsencrypt/buypass. See the earlier mentioned reference: https://community.letsencrypt.org/t/the-way-domain-name-in-the-subject-of-the-certificate-request-treated/116107 For the order, containing...

Thanks for the reply and clarification @jsha! Is there a RFC8555 divergences document for pebble, similarly, as boulder has the following: https://github.com/letsencrypt/boulder/blob/master/docs/acme-divergences.md ? > If you'd like to maximize compatibility...

So, I implemented a workaround in my client: https://github.com/bruncsak/ght-acme.sh/commit/0f27ce73a1517be771785f89bac6995cff836103

Oh, I see what you mean. All ACME servers are compatible with RFC8555, but different additional restriction on the CSR are not excluded which leads to incompatible behavior. So my...

So here is the patch to my client, fixing the comments: https://github.com/bruncsak/ght-acme.sh/commit/3d46cf6aa3377a113bd36ec95cdce509e3533b50

Today pebble accepts domain name in the Subject commonName, but it totally disregards its value, like it would not be there. Your proposed change would be more than cosmetics; before...

Yes, that could be good to have a specific error message for that case. What about the case where one identifier is in the order, and this identifier is in...

Sorry for the later answer, there is a second way. You may use the `gen-csr.sh` utility as well. I just updated it, fixing some bugs.