# Questions re: Beginning Issuance from R3

**URL:** <https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026>\
**Category:** Issuance Tech\
**Created:** [November 24, 2020, 8:13pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026 "2020-11-24T20:13:05Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [December 2, 2020, 10:26pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/22 "2020-12-02T22:26:52Z")

</div>

> [@andygabby](#):
>
> I'll make sure we get that updated.

Don't forget the part about OCSP URIs in the intermediates, as they are _gone_ for R3/R4 and E1/E2 as far as I remember.

---

<div class="post-metadata">

**Author:** ![doom369](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/doom369/32/45043_2.png) [@doom369](https://community.letsencrypt.org/u/doom369)\
**Post date:** [December 4, 2020, 6:58pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/23 "2020-12-04T18:58:22Z")

</div>

Hello. Sorry for my noob question.  
Is there any chance for the new certificate (R3) to support the old (X3) intermediate cert? Maybe somehow via alternate URL or something like that? We have a problem with some of our clients who hardcoded the certificates issuer footprint on their end, so they now can't establish a connection with the new certificates.

---

<div class="post-metadata">

**Author:** ![petercooperjr](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/petercooperjr/32/84698_2.png) [@petercooperjr](https://community.letsencrypt.org/u/petercooperjr)\
**Post date:** [December 4, 2020, 7:19pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/24 "2020-12-04T19:19:36Z")

</div>

> [@doom369](#):
>
> Is there any chance for the new certificate (R3) to support the old (X3) intermediate cert? Maybe somehow via alternate URL or something like that? We have a problem with some of our clients who hardcoded the certificates issuer footprint on their end, so they now can't establish a connection with the new certificates.

No, that's not really how it works. Any system getting a new certificate needs to also download the intermediate that it was signed with and configure the server to serve it alongside the certificate. Anyone who is trying to validate that a certificate is actually signed by Let's Encrypt needs to check the full certificate chain and validate it against a root certificate, not any specific intermediate certificate. While they did just change the intermediate for the first time in a long while, it could have changed at any point and can change again at any point (such as if the disaster-recovery intermediates start getting used).

If you _really_ need to track the intermediates for some reason (which I guess maybe [some DANE implementations do](https://community.letsencrypt.org/t/dane-and-upcoming-le-issuer-certs/134172)?) then you need to subscribe to the [API Announcements](https://community.letsencrypt.org/t/about-the-api-announcements-category/23836) to get notified about upcoming new intermediates so you can be proactive about adding them to your system. But there are [several that could be used](https://letsencrypt.org/certificates/) so you'd need to be prepared for certificates that are signed by any of them.

---

<div class="post-metadata">

**Author:** ![doom369](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/doom369/32/45043_2.png) [@doom369](https://community.letsencrypt.org/u/doom369)\
**Post date:** [December 4, 2020, 7:35pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/25 "2020-12-04T19:35:53Z")

</div>

Thanks for the clarification. 😢

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [December 4, 2020, 7:37pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/26 "2020-12-04T19:37:36Z")

</div>

> [@doom369](#):
>
> We have a problem with some of our clients who hardcoded the certificates issuer footprint on their end (…)

That was an unfortunate and ill-considered design then.

---

<div class="post-metadata">

**Author:** ![petercooperjr](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/petercooperjr/32/84698_2.png) [@petercooperjr](https://community.letsencrypt.org/u/petercooperjr)\
**Post date:** [December 4, 2020, 7:44pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/27 "2020-12-04T19:44:44Z")

</div>

> [@petercooperjr](#):
>
> you need to subscribe to the [API Announcements](https://community.letsencrypt.org/t/about-the-api-announcements-category/23836) to get notified about upcoming new intermediates

And while I just gave this advice, it might not have actually given people much time to prepare. There was a notification on the _blog_ [on Sept. 17](https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html), but the only notice on the API Announcements category [said that it might happen as soon as that day](https://community.letsencrypt.org/t/beginning-issuance-from-r3/139018). So it may be that if you want to learn of new intermediates with enough time to add them to your systems that you need to watch both the API Announcements and the blog, though I don't see any good way to get notified of new blog posts (though one might be able to easily integrate with the RSS feed of it somehow).

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [December 4, 2020, 8:08pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/28 "2020-12-04T20:08:09Z")

</div>

Shouldn't be a matter anyway @petercooperjr, the [integration guide](https://letsencrypt.org/docs/integration-guide/) is very clear:

> For intermediate changes in particular, you should not hardcode the intermediate to use, but should use the [`Link: rel="up"`](https://tools.ietf.org/html/rfc8555#section-7.4.2) header from the ACME protocol, since intermediates are likely to change.

---

<div class="post-metadata">

**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\
**Post date:** [December 4, 2020, 8:14pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/29 "2020-12-04T20:14:55Z")

</div>

when I first wrote a client several years ago, very very very few clients implemented this. i don't think certbot did this for quite some time either.

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [December 4, 2020, 8:16pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/30 "2020-12-04T20:16:37Z")

</div>

I would hope a client written many many years ago has seen some updates in the mean while?

You can't just pretend you're an ostrich and stick your head in the sand..

---

<div class="post-metadata">

**Author:** ![aarongable](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/aarongable/32/42043_2.png) [@aarongable](https://community.letsencrypt.org/u/aarongable)\
**Post date:** [December 4, 2020, 8:33pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/31 "2020-12-04T20:33:27Z")

</div>

We are keeping an eye on things to monitor the extent of any breakage due to this change. So far, we have observed very few domains continuing to serve the X3 intermediate in their chain despite having gotten an R3-issued end-entity cert during their scheduled renewal. For those few domains where we have observed this failure mode (which is not necessarily a full breakage: browsers _may_ still be able to verify the end-entity cert despite the wrong chain being served), we are working on determining commonalities so we can reach out to the appropriate ACME client developers.

Note, however, that even APIv1 ACME clients which do hard-code the `/acme/issuer-cert` API path rather than getting it from the `<link rel="up">` attribute are not broken by this change: we changed the cert which is served at `/acme/issuer-cert` from X3 to R3. The only clients which would be broken by this change are those that bundle the intermediate cert directly, fetch it from a hardcoded non-ACME url (e.g. from the AIA url), or fetch the intermediate upon first issuance but then ignore it during renewals.

---

<div class="post-metadata">

**Author:** ![ietf-dane](https://avatars.discourse-cdn.com/v4/letter/i/90ced4/32.png) [@ietf-dane](https://community.letsencrypt.org/u/ietf-dane)\
**Post date:** [December 5, 2020, 6:06am UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/32 "2020-12-05T06:06:57Z")

</div>

Indeed some DANE users had published TLSA records that match only X3. Since the announcement many have updated their TLSA records to also match R3/R4, but some have [procrastinated](http://dnssec-stats.ant.isi.edu/~viktor/x3hosts.html). They'll have to make changes soon, it looks like X3 is now retired, and all new issuance is via R3.

A handful of domains monitored by the [DANE survey](https://stats.dnssec-tools.org) in fact failed validation today and have been notified of the problem. Most are unaffected (use "3 1 1" records, or have already added R3/R4). Probably a few more procrastinators will only take action after a failure in the coming days...

---

<div class="post-metadata">

**Author:** ![jillian](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jillian/32/11635_2.png) [@jillian](https://community.letsencrypt.org/u/jillian)\
**Post date:** [December 7, 2020, 8:37pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/33 "2020-12-07T20:37:06Z")

</div>

3 posts were split to a new topic: [Certify the Web Client Issues Possibly R3 Change](https://community.letsencrypt.org/t/certify-the-web-client-issues-possibly-r3-change/139995)

---

<div class="post-metadata">

**Author:** ![bmmsilva](https://avatars.discourse-cdn.com/v4/letter/b/c68b51/32.png) [@bmmsilva](https://community.letsencrypt.org/u/bmmsilva)\
**Post date:** [December 8, 2020, 12:40pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/34 "2020-12-08T12:40:21Z")

</div>

We're facing an issue with our IoT devices that were bundled with the intermediate certificate (X3) and when our server renew the certificate, they lost the ability to connect with server which prevent us from update them remotely.  
Is it possible to request a certificate based on the intermediate X3 just to gave us a time window to update our devices? Or there's any procedure for recovery where we can request a certificate with that specific chain to Let's Encrypt?

---

<div class="post-metadata">

**Author:** ![petercooperjr](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/petercooperjr/32/84698_2.png) [@petercooperjr](https://community.letsencrypt.org/u/petercooperjr)\
**Post date:** [December 8, 2020, 1:43pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/35 "2020-12-08T13:43:19Z")

</div>

What was your plan when X3 expired in 2021, or if they needed to bring the disaster recovery intermediate X4 online?

If your servers followed the best practice of renewing every 60 days, you should still have your older server certificate somewhere that was signed by X3 that should expire at some point in the next month. If you can restore that certificate and use it for your server, you should have a small window until it actually expires. I recommend you update your devices to chain to the ISRG root (and also include some other CAs rather than relying on Let's Encrypt being around forever) instead of a specific intermediate. Intermediates can change at any time.

You may also want to check out this thread by someone else who was looking at what to put in the trust store of their IoT devices, which has some additional ideas and cautions:

> [@Including "ISRG Root X1" with my IoT firmware before hand](https://community.letsencrypt.org/t/including-isrg-root-x1-with-my-iot-firmware-before-hand/138218):
>
> C…

---

<div class="post-metadata">

**Author:** ![bmmsilva](https://avatars.discourse-cdn.com/v4/letter/b/c68b51/32.png) [@bmmsilva](https://community.letsencrypt.org/u/bmmsilva)\
**Post date:** [December 9, 2020, 8:06pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/36 "2020-12-09T20:06:00Z")

</div>

Thank you for your help and for the reference to that thread.  
Regarding your first question, we updated the application so it can load multiple certificates into a cert pool, which is then used by the client it tries to establish a connection with server.  
Regarding your suggestion to recover the older certificate, it wasn't possible, because the certificates are managed by cert-manager (on a kubernetes cluster) which replaces the older ones when their are renewed.

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [December 9, 2020, 9:19pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/37 "2020-12-09T21:19:21Z")

</div>

Luckily you've got a fairly recent backup from which you can pull the older certificate 😉

---

<div class="post-metadata">

**Author:** ![ritturoy](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ritturoy/32/45239_2.png) [@ritturoy](https://community.letsencrypt.org/u/ritturoy)\
**Post date:** [December 9, 2020, 10:59pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/38 "2020-12-09T22:59:33Z")

</div>

Hi,  
My Salesforce client makes a callout to one of our internal services which has the new R3 intermediate cert. The integration is broken now. Salesforce maintains the list of trusted root certificates. Since the intermediate cert has changed, should I contact Salesforce to get their certificate chain updated?

---

<div class="post-metadata">

**Author:** ![griffin](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/griffin/32/50204_2.png) [@griffin](https://community.letsencrypt.org/u/griffin)\
**Post date:** [December 9, 2020, 11:11pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/39 "2020-12-09T23:11:19Z")

</div>

Welcome to the Let's Encrypt Community, Rittu 🙂

That sounds wise to me, so long as you confirm the exact problem first. See the posts directly below from @Osiris and @rg305. Given that intermediate certificates can functionally change at any point in time, they need to keep things updated. They can use the following to get their information straight:

> **[Chain of Trust - Let's Encrypt - Free SSL/TLS Certificates](https://letsencrypt.org/certificates/)**
>
> Last updated: Dec 8, 2020 
> Root Certificates Our roots are kept safely offline. We issue end-entity certificates to subscribers from the intermediates in the next section. For additional compatibility as we submit our new Root X2 to various root...

---

<div class="post-metadata">

**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\
**Post date:** [December 9, 2020, 11:24pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/40 "2020-12-09T23:24:59Z")

</div>

> [@ritturoy](#):
>
> Since the intermediate cert has changed, should I contact Salesforce to get their certificate chain updated?

A TLS client shouldn't rely on intermediates in their trusted certificate store, but on root certificates. And the root certificate hasn't changed (yet). Therefore, it might be possible that your server isn't correctly configured or Salesforce is doing stupid things.

---

<div class="post-metadata">

**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\
**Post date:** [December 9, 2020, 11:33pm UTC](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026/41 "2020-12-09T23:33:35Z")

</div>

> [@ritturoy](#):
>
> should I contact Salesforce to get their certificate chain updated?

Short answer: No (not for that reason).  
Longer answer: You might have to contact them if they are to blame for this problem (for other reasons).  
Much Longer answer: You need to figure out where the problem is, so that you can get the right person to fix it.

[Previous page](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026.md?page=1)

[Next page](https://community.letsencrypt.org/t/questions-re-beginning-issuance-from-r3/139026.md?page=3)
