# The way domain name in the subject of the certificate request treated

**URL:** <https://community.letsencrypt.org/t/the-way-domain-name-in-the-subject-of-the-certificate-request-treated/116107>\
**Category:** Client dev\
**Created:** [March 11, 2020, 3:30pm UTC](https://community.letsencrypt.org/t/the-way-domain-name-in-the-subject-of-the-certificate-request-treated/116107 "2020-03-11T15:30:43Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![bruncsak](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruncsak/32/18414_2.png) [@bruncsak](https://community.letsencrypt.org/u/bruncsak)\
**Post date:** [March 11, 2020, 3:30pm UTC](https://community.letsencrypt.org/t/the-way-domain-name-in-the-subject-of-the-certificate-request-treated/116107/1 "2020-03-11T15:30:44Z")

</div>

I see different behavior domain name treated in pebble versus letsencrypt/bypass staging ACME servers. If there is a domain name in the subject of the CSR CN=… , which is not part of the SAN, letsencrypt and bypass requires validation identifier for that domain name too. However, pebble totally disregards what is in the Subject’s common name of the CSR, and replaces the subject for the certificate, having a domain name from the SAN section.

Letsencrypt’s error:

```auto
{
  "type": "urn:ietf:params:acme:error:unauthorized",
  "detail": "Error finalizing order :: Order includes different number of names than CSR specifies",
  "status": 403
}

```

Bypass’ error:

```auto
{"type":"urn:ietf:params:acme:error:badCSR","detail":"CSR and order identifiers differ","code":403,"message":"BAD_CSR","details":"HTTP 403 Forbidden"}

```

Pebble’s error:

```auto
{
   "type": "urn:ietf:params:acme:error:unauthorized",
   "detail": "Order includes different number of DNSnames identifiers than CSR specifies",
   "status": 403
}

```

With a specific CSR having the above qualification for a test case, I have to decide which test server to fail. Pebble or letsencrypt/bypass.

Or, my ACME client should strait refuse a CSR having a a domain only in the subject CN and not part of the SAN?

Or, do I have to put different code in my client [https://github.com/bruncsak/ght-acme.sh](https://github.com/bruncsak/ght-acme.sh) for pebble than for the other ACME servers?

The RFC8555 is clear about this:

```auto
The CSR MUST indicate the exact same
   set of requested identifiers as the initial newOrder request.
   Identifiers of type "dns" MUST appear either in the commonName
   portion of the requested subject name or in an extensionRequest
   attribute [RFC2985] requesting a subjectAltName extension, or both.

```

I think that is an issue to submit to pebble development, they fail implementing that section of the RFC.

---

<div class="post-metadata">

**Author:** ![bruncsak](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruncsak/32/18414_2.png) [@bruncsak](https://community.letsencrypt.org/u/bruncsak)\
**Post date:** [March 11, 2020, 6:45pm UTC](https://community.letsencrypt.org/t/the-way-domain-name-in-the-subject-of-the-certificate-request-treated/116107/2 "2020-03-11T18:45:48Z")

</div>

The issue is:

> <https://github.com/letsencrypt/pebble/issues/304>
>
> RFC8555 tells:
> The CSR MUST indicate the exact same
> set of requested identifiers as the initial newOrder request.
> Identifiers of type...

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [April 10, 2020, 6:45pm UTC](https://community.letsencrypt.org/t/the-way-domain-name-in-the-subject-of-the-certificate-request-treated/116107/3 "2020-04-10T18:45:51Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.