| 2019-07-23 22:33:52 |
Brad Warren |
bug |
|
|
added bug |
| 2019-07-23 22:38:52 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2019-07-23 22:39:02 |
Robie Basak |
nominated for series |
|
Ubuntu Xenial |
|
| 2019-07-23 22:39:02 |
Robie Basak |
bug task added |
|
python-certbot (Ubuntu Xenial) |
|
| 2019-07-23 22:39:02 |
Robie Basak |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-07-23 22:39:02 |
Robie Basak |
bug task added |
|
python-certbot (Ubuntu Bionic) |
|
| 2019-07-23 22:39:10 |
Robie Basak |
python-certbot (Ubuntu Xenial): status |
New |
Triaged |
|
| 2019-07-23 22:39:13 |
Robie Basak |
python-certbot (Ubuntu Bionic): status |
New |
Triaged |
|
| 2019-07-23 22:39:16 |
Robie Basak |
python-certbot (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2019-07-23 22:39:19 |
Robie Basak |
python-certbot (Ubuntu Bionic): importance |
Undecided |
High |
|
| 2019-07-26 23:34:40 |
James Hebden |
python-certbot (Ubuntu): assignee |
|
James Hebden (ec0) |
|
| 2019-07-26 23:34:43 |
James Hebden |
python-certbot (Ubuntu Xenial): assignee |
|
James Hebden (ec0) |
|
| 2019-07-26 23:34:47 |
James Hebden |
python-certbot (Ubuntu Bionic): assignee |
|
James Hebden (ec0) |
|
| 2019-10-03 19:52:40 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Disco |
|
| 2019-10-03 19:52:40 |
Andreas Hasenack |
bug task added |
|
python-certbot (Ubuntu Disco) |
|
| 2019-10-03 19:52:40 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Eoan |
|
| 2019-10-03 19:52:40 |
Andreas Hasenack |
bug task added |
|
python-certbot (Ubuntu Eoan) |
|
| 2019-10-03 19:52:48 |
Andreas Hasenack |
python-certbot (Ubuntu Disco): status |
New |
Fix Released |
|
| 2019-10-03 19:52:51 |
Andreas Hasenack |
python-certbot (Ubuntu Eoan): status |
New |
Fix Released |
|
| 2019-10-03 21:42:09 |
Andreas Hasenack |
bug |
|
|
added subscriber Andreas Hasenack |
| 2019-10-10 20:06:12 |
Andreas Hasenack |
python-certbot (Ubuntu Xenial): assignee |
James Hebden (ec0) |
Andreas Hasenack (ahasenack) |
|
| 2019-10-10 20:06:15 |
Andreas Hasenack |
python-certbot (Ubuntu Bionic): assignee |
James Hebden (ec0) |
Andreas Hasenack (ahasenack) |
|
| 2019-10-10 20:06:19 |
Andreas Hasenack |
python-certbot (Ubuntu Xenial): status |
Triaged |
In Progress |
|
| 2019-10-10 20:06:22 |
Andreas Hasenack |
python-certbot (Ubuntu Bionic): status |
Triaged |
In Progress |
|
| 2019-10-10 20:06:43 |
Andreas Hasenack |
description |
This bug affects the python-certbot packages in Xenial and Bionic. Cosmic and newer is unaffected.
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
This bug affects the python-certbot packages in Xenial and Bionic. Cosmic and newer is unaffected.
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. |
|
| 2019-10-10 20:12:47 |
Andreas Hasenack |
description |
[Impact]
* An explanation of the effects of the bug on users and
* justification for backporting the fix to the stable release.
* In addition, it is helpful, but not required, to include an
explanation of how the upload fixes this bug.
[Test Case]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
This bug affects the python-certbot packages in Xenial and Bionic. Cosmic and newer is unaffected.
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. |
[Impact]
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages.
[Test Case]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
This bug affects the python-certbot packages in Xenial and Bionic. Cosmic and newer is unaffected.
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. |
|
| 2019-10-10 20:19:18 |
Andreas Hasenack |
description |
[Impact]
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages.
[Test Case]
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
This bug affects the python-certbot packages in Xenial and Bionic. Cosmic and newer is unaffected.
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. |
[Impact]
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages.
[Test Case]
The test case will be about requesting a real certificate from Let's Encrypt. You need to make sure the host where you are running these instructions:
- is reachable from the internet on port 80
- has a public IP
- said public IP has a valid DNS record under a public domain name
* install certbot with the apache plugin:
sudo apt install python-certbot-apache certbot
* run the certbot command:
sudo certbot run
* After the question about your email address, it will initiate a connection to an ACME server. The old packages will use a V1 server, like this:
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
* The new packages will use a v2 server, like this:
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
The above (use a v2 server) is the SRU verification in a nutshell. Of course, obtaining the certificate at the end should still work, but we want to verify with this update that the v2 server was used.
Depending on the date this test is run, the acme v1 server might have been deactivated, in which case you will get this error (with the old packages):
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
An unexpected error occurred:
The client lacks sufficient authorization :: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.
Please see the logfiles in /var/log/letsencrypt for more details.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
This bug affects the python-certbot packages in Xenial and Bionic. Cosmic and newer is unaffected.
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. |
|
| 2019-10-10 20:22:06 |
Andreas Hasenack |
description |
[Impact]
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages.
[Test Case]
The test case will be about requesting a real certificate from Let's Encrypt. You need to make sure the host where you are running these instructions:
- is reachable from the internet on port 80
- has a public IP
- said public IP has a valid DNS record under a public domain name
* install certbot with the apache plugin:
sudo apt install python-certbot-apache certbot
* run the certbot command:
sudo certbot run
* After the question about your email address, it will initiate a connection to an ACME server. The old packages will use a V1 server, like this:
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
* The new packages will use a v2 server, like this:
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
The above (use a v2 server) is the SRU verification in a nutshell. Of course, obtaining the certificate at the end should still work, but we want to verify with this update that the v2 server was used.
Depending on the date this test is run, the acme v1 server might have been deactivated, in which case you will get this error (with the old packages):
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
An unexpected error occurred:
The client lacks sufficient authorization :: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.
Please see the logfiles in /var/log/letsencrypt for more details.
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
This bug affects the python-certbot packages in Xenial and Bionic. Cosmic and newer is unaffected.
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. |
[Impact]
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages.
[Test Case]
The test case will be about requesting a real certificate from Let's Encrypt. You need to make sure the host where you are running these instructions:
- is reachable from the internet on port 80
- has a public IP
- said public IP has a valid DNS record under a public domain name
* install certbot with the apache plugin:
sudo apt install python-certbot-apache certbot
* run the certbot command:
sudo certbot run
* After the question about your email address, it will initiate a connection to an ACME server. The old packages will use a V1 server, like this:
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
* The new packages will use a v2 server, like this:
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
The above (use a v2 server) is the SRU verification in a nutshell. Of course, obtaining the certificate at the end should still work, but we want to verify with this update that the v2 server was used.
Depending on the date this test is run, the acme v1 server might have been deactivated, in which case you will get this error (with the old packages):
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
An unexpected error occurred:
The client lacks sufficient authorization :: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.
Please see the logfiles in /var/log/letsencrypt for more details.
* To complete the test, let's test renewing the certificate, and then revoke it:
sudo certbot --dry-run renew
* list certificates, taking note of the certificate path:
sudo certbot certificate
* revoke the certificate, using the certificate path obtained in the previous step:
sudo certbot --cert-path <path-from-previous-step> revoke
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
This bug affects the python-certbot packages in Xenial and Bionic. Cosmic and newer is unaffected.
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. |
|
| 2019-10-10 20:26:48 |
Andreas Hasenack |
description |
[Impact]
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages.
[Test Case]
The test case will be about requesting a real certificate from Let's Encrypt. You need to make sure the host where you are running these instructions:
- is reachable from the internet on port 80
- has a public IP
- said public IP has a valid DNS record under a public domain name
* install certbot with the apache plugin:
sudo apt install python-certbot-apache certbot
* run the certbot command:
sudo certbot run
* After the question about your email address, it will initiate a connection to an ACME server. The old packages will use a V1 server, like this:
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
* The new packages will use a v2 server, like this:
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
The above (use a v2 server) is the SRU verification in a nutshell. Of course, obtaining the certificate at the end should still work, but we want to verify with this update that the v2 server was used.
Depending on the date this test is run, the acme v1 server might have been deactivated, in which case you will get this error (with the old packages):
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
An unexpected error occurred:
The client lacks sufficient authorization :: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.
Please see the logfiles in /var/log/letsencrypt for more details.
* To complete the test, let's test renewing the certificate, and then revoke it:
sudo certbot --dry-run renew
* list certificates, taking note of the certificate path:
sudo certbot certificate
* revoke the certificate, using the certificate path obtained in the previous step:
sudo certbot --cert-path <path-from-previous-step> revoke
[Regression Potential]
* discussion of how regressions are most likely to manifest as a result of this change.
* It is assumed that any SRU candidate patch is well-tested before
upload and has a low overall risk of regression, but it's important
to make the effort to think about what ''could'' happen in the
event of a regression.
* This both shows the SRU team that the risks have been considered,
and provides guidance to testers in regression-testing the SRU.
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
This bug affects the python-certbot packages in Xenial and Bionic. Cosmic and newer is unaffected.
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. |
[Impact]
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages.
[Test Case]
The test case will be about requesting a real certificate from Let's Encrypt. You need to make sure the host where you are running these instructions:
- is reachable from the internet on port 80
- has a public IP
- said public IP has a valid DNS record under a public domain name
* install certbot with the apache plugin:
sudo apt install python-certbot-apache certbot
* run the certbot command:
sudo certbot run
* After the question about your email address, it will initiate a connection to an ACME server. The old packages will use a V1 server, like this:
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
* The new packages will use a v2 server, like this:
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
The above (use a v2 server) is the SRU verification in a nutshell. Of course, obtaining the certificate at the end should still work, but we want to verify with this update that the v2 server was used.
Depending on the date this test is run, the acme v1 server might have been deactivated, in which case you will get this error (with the old packages):
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
An unexpected error occurred:
The client lacks sufficient authorization :: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.
Please see the logfiles in /var/log/letsencrypt for more details.
* To complete the test, let's test renewing the certificate, and then revoke it:
sudo certbot --dry-run renew
* list certificates, taking note of the certificate path:
sudo certbot certificate
* revoke the certificate, using the certificate path obtained in the previous step:
sudo certbot --cert-path <path-from-previous-step> revoke
* As a final testing step, list the systemd timers, to make sure the certbot one is active:
$ sudo systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Fri 2019-10-11 04:38:08 UTC 8h left Thu 2019-10-10 19:24:55 UTC 1h 1min ago certbot.timer certbot.service
...
[Regression Potential]
The fix adopted for this bug is a backport from a newer package (cosmic). No changes at all for bionic, but xenial needed some:
- no python3 in xenial, so I had to go back to py2. Upstream gave us their ok (see comment #8)
- debhelper 9 instead of 11, that required some changes too, specially around systemd
- build-depends on sphinx >= 1.6 had to be removed, and was done following upstream's guidance (see comment #6)
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
This bug affects the python-certbot packages in Xenial and Bionic. Cosmic and newer is unaffected.
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. |
|
| 2019-10-10 20:32:57 |
Andreas Hasenack |
description |
[Impact]
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages.
[Test Case]
The test case will be about requesting a real certificate from Let's Encrypt. You need to make sure the host where you are running these instructions:
- is reachable from the internet on port 80
- has a public IP
- said public IP has a valid DNS record under a public domain name
* install certbot with the apache plugin:
sudo apt install python-certbot-apache certbot
* run the certbot command:
sudo certbot run
* After the question about your email address, it will initiate a connection to an ACME server. The old packages will use a V1 server, like this:
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
* The new packages will use a v2 server, like this:
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
The above (use a v2 server) is the SRU verification in a nutshell. Of course, obtaining the certificate at the end should still work, but we want to verify with this update that the v2 server was used.
Depending on the date this test is run, the acme v1 server might have been deactivated, in which case you will get this error (with the old packages):
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
An unexpected error occurred:
The client lacks sufficient authorization :: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.
Please see the logfiles in /var/log/letsencrypt for more details.
* To complete the test, let's test renewing the certificate, and then revoke it:
sudo certbot --dry-run renew
* list certificates, taking note of the certificate path:
sudo certbot certificate
* revoke the certificate, using the certificate path obtained in the previous step:
sudo certbot --cert-path <path-from-previous-step> revoke
* As a final testing step, list the systemd timers, to make sure the certbot one is active:
$ sudo systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Fri 2019-10-11 04:38:08 UTC 8h left Thu 2019-10-10 19:24:55 UTC 1h 1min ago certbot.timer certbot.service
...
[Regression Potential]
The fix adopted for this bug is a backport from a newer package (cosmic). No changes at all for bionic, but xenial needed some:
- no python3 in xenial, so I had to go back to py2. Upstream gave us their ok (see comment #8)
- debhelper 9 instead of 11, that required some changes too, specially around systemd
- build-depends on sphinx >= 1.6 had to be removed, and was done following upstream's guidance (see comment #6)
[Other Info]
* Anything else you think is useful to include
* Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board
* and address these questions in advance
[Original Description]
This bug affects the python-certbot packages in Xenial and Bionic. Cosmic and newer is unaffected.
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. |
[Impact]
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages.
[Test Case]
The test case will be about requesting a real certificate from Let's Encrypt. You need to make sure the host where you are running these instructions:
- is reachable from the internet on port 80
- has a public IP
- said public IP has a valid DNS record under a public domain name
* install certbot with the apache plugin:
sudo apt install python-certbot-apache certbot
* run the certbot command:
sudo certbot run
* After the question about your email address, it will initiate a connection to an ACME server. The old packages will use a V1 server, like this:
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
* The new packages will use a v2 server, like this:
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
The above (use a v2 server) is the SRU verification in a nutshell. Of course, obtaining the certificate at the end should still work, but we want to verify with this update that the v2 server was used.
Depending on the date this test is run, the acme v1 server might have been deactivated, in which case you will get this error (with the old packages):
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
An unexpected error occurred:
The client lacks sufficient authorization :: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.
Please see the logfiles in /var/log/letsencrypt for more details.
* To complete the test, let's test renewing the certificate, and then revoke it:
sudo certbot --dry-run renew
* list certificates, taking note of the certificate path:
sudo certbot certificate
* revoke the certificate, using the certificate path obtained in the previous step:
sudo certbot --cert-path <path-from-previous-step> revoke
* As a final testing step, list the systemd timers, to make sure the certbot one is active:
$ sudo systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Fri 2019-10-11 04:38:08 UTC 8h left Thu 2019-10-10 19:24:55 UTC 1h 1min ago certbot.timer certbot.service
...
[Regression Potential]
The fix adopted for this bug is a backport from a newer package (cosmic). No changes at all for bionic, but xenial needed some:
- no python3 in xenial, so I had to go back to py2. Upstream gave us their ok (see comment #8)
- debhelper 9 instead of 11, that required some changes too, specially around systemd
- build-depends on sphinx >= 1.6 had to be removed, and was done following upstream's guidance (see comment #6)
[Other Info]
This SRU depends on bug #1836823 being released first, as the newer python-acme is required.
[Original Description]
This bug affects the python-certbot packages in Xenial and Bionic. Cosmic and newer is unaffected.
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. |
|
| 2019-10-10 21:12:11 |
Andreas Hasenack |
description |
[Impact]
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages.
[Test Case]
The test case will be about requesting a real certificate from Let's Encrypt. You need to make sure the host where you are running these instructions:
- is reachable from the internet on port 80
- has a public IP
- said public IP has a valid DNS record under a public domain name
* install certbot with the apache plugin:
sudo apt install python-certbot-apache certbot
* run the certbot command:
sudo certbot run
* After the question about your email address, it will initiate a connection to an ACME server. The old packages will use a V1 server, like this:
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
* The new packages will use a v2 server, like this:
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
The above (use a v2 server) is the SRU verification in a nutshell. Of course, obtaining the certificate at the end should still work, but we want to verify with this update that the v2 server was used.
Depending on the date this test is run, the acme v1 server might have been deactivated, in which case you will get this error (with the old packages):
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
An unexpected error occurred:
The client lacks sufficient authorization :: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.
Please see the logfiles in /var/log/letsencrypt for more details.
* To complete the test, let's test renewing the certificate, and then revoke it:
sudo certbot --dry-run renew
* list certificates, taking note of the certificate path:
sudo certbot certificate
* revoke the certificate, using the certificate path obtained in the previous step:
sudo certbot --cert-path <path-from-previous-step> revoke
* As a final testing step, list the systemd timers, to make sure the certbot one is active:
$ sudo systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Fri 2019-10-11 04:38:08 UTC 8h left Thu 2019-10-10 19:24:55 UTC 1h 1min ago certbot.timer certbot.service
...
[Regression Potential]
The fix adopted for this bug is a backport from a newer package (cosmic). No changes at all for bionic, but xenial needed some:
- no python3 in xenial, so I had to go back to py2. Upstream gave us their ok (see comment #8)
- debhelper 9 instead of 11, that required some changes too, specially around systemd
- build-depends on sphinx >= 1.6 had to be removed, and was done following upstream's guidance (see comment #6)
[Other Info]
This SRU depends on bug #1836823 being released first, as the newer python-acme is required.
[Original Description]
This bug affects the python-certbot packages in Xenial and Bionic. Cosmic and newer is unaffected.
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. |
[Impact]
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages.
[Test Case]
The test case will be about requesting a real certificate from Let's Encrypt. You need to make sure the host where you are running these instructions:
- is reachable from the internet on port 80
- has a public IP
- said public IP has a valid DNS record under a public domain name
* install certbot with the apache plugin:
sudo apt install python-certbot-apache certbot
* run the certbot command:
sudo certbot run
* After the question about your email address, it will initiate a connection to an ACME server. The old packages will use a V1 server, like this:
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
* The new packages will use a v2 server, like this:
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
The above (use a v2 server) is the SRU verification in a nutshell. Of course, obtaining the certificate at the end should still work, but we want to verify with this update that the v2 server was used.
Depending on the date this test is run, the acme v1 server might have been deactivated, in which case you will get this error (with the old packages):
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
An unexpected error occurred:
The client lacks sufficient authorization :: Account creation on ACMEv1 is disabled. Please upgrade your ACME client to a version that supports ACMEv2 / RFC 8555. See https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430 for details.
Please see the logfiles in /var/log/letsencrypt for more details.
* To complete the test, let's test renewing the certificate, and then revoke it:
sudo certbot --dry-run renew
* list certificates, taking note of the certificate path:
sudo certbot certificate
* revoke the certificate, using the certificate path obtained in the previous step:
sudo certbot --cert-path <path-from-previous-step> revoke
* As a final testing step, list the systemd timers, to make sure the certbot one is active:
$ sudo systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Fri 2019-10-11 04:38:08 UTC 8h left Thu 2019-10-10 19:24:55 UTC 1h 1min ago certbot.timer certbot.service
...
[Regression Potential]
The fix adopted for this bug is a backport from a newer package (cosmic). I included a fix that was found in debian's 0.28 package, but xenial needed more changes:
- not all python3 deps are in xenial, so I had to go back to py2. Upstream gave us their ok (see comment #8)
- debhelper 9 instead of 11, that required some changes too, specially around systemd
- build-depends on sphinx >= 1.6 had to be removed, and was done following upstream's guidance (see comment #6)
[Other Info]
This SRU depends on bug #1836823 being released first, as the newer python-acme is required.
[Original Description]
This bug affects the python-certbot packages in Xenial and Bionic. Cosmic and newer is unaffected.
To do almost anything in the ACME protocol used by Let's Encrypt and Certbot including obtaining and revoking certificates, you need to first create an account with the ACME server. Starting in November, Certbot will no longer be able to do that with its default configuration. This is because as part of pushing people towards the standardized version of the protocol, Let's Encrypt is no longer letting people create new accounts on their ACMEv1 endpoint. More details about this change can be found at https://community.letsencrypt.org/t/end-of-life-plan-for-acmev1/88430.
What this means for Ubuntu users is that new Certbot installations on affected systems would need to be given the URL of an alternative ACME server in order to work. Existing installations would be unaffected for now as long as they don't deactivate their account or delete its credentials. They will have additional problems in the future due to the additional deprecations described in the link above.
To solve this problem, I recommend backporting the Certbot packages from Cosmic to Bionic and Xenial. There are no breaking changes to the public interfaces between versions and I think this results in the smallest change to the packages that would resolve this problem while sticking to well tested packages. |
|
| 2019-10-18 18:20:25 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/python-certbot/+git/python-certbot/+merge/374373 |
|
| 2019-10-18 18:39:35 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/python-certbot/+git/python-certbot/+merge/374376 |
|
| 2019-10-18 18:49:06 |
Andreas Hasenack |
merge proposal linked |
|
https://code.launchpad.net/~ahasenack/ubuntu/+source/python-certbot/+git/python-certbot/+merge/374375 |
|
| 2019-10-21 17:21:09 |
Robie Basak |
python-certbot (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2019-10-21 17:21:13 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-10-21 17:21:14 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2019-10-21 17:21:18 |
Robie Basak |
tags |
|
verification-needed verification-needed-bionic |
|
| 2019-10-21 17:22:09 |
Robie Basak |
python-certbot (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2019-10-21 17:22:16 |
Robie Basak |
tags |
verification-needed verification-needed-bionic |
verification-needed verification-needed-bionic verification-needed-xenial |
|
| 2019-10-25 20:56:55 |
Andreas Hasenack |
tags |
verification-needed verification-needed-bionic verification-needed-xenial |
verification-done-xenial verification-needed verification-needed-bionic |
|
| 2019-10-25 21:26:15 |
Andreas Hasenack |
tags |
verification-done-xenial verification-needed verification-needed-bionic |
verification-done-bionic verification-done-xenial verification-needed |
|
| 2019-10-29 03:01:48 |
Mathew Hodson |
tags |
verification-done-bionic verification-done-xenial verification-needed |
verification-done-bionic verification-done-xenial |
|
| 2019-10-29 17:23:48 |
Launchpad Janitor |
python-certbot (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-10-29 17:23:52 |
Robie Basak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-10-29 17:24:03 |
Launchpad Janitor |
python-certbot (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
