[GH-ISSUE #285] gentoo & startssl troubles, use letsencrypt certificate #227

Closed
opened 2026-02-26 09:36:43 +03:00 by kerem · 4 comments
Owner

Originally created by @ThomasWaldmann on GitHub (Nov 21, 2016).
Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/285

Originally assigned to: @ThomasWaldmann on GitHub.

I got notified that gentoo removed the root cert of startssl, making TLS connections to nsupdate.info fail.

We should use letsencrypt certificates.

Originally created by @ThomasWaldmann on GitHub (Nov 21, 2016). Original GitHub issue: https://github.com/nsupdate-info/nsupdate.info/issues/285 Originally assigned to: @ThomasWaldmann on GitHub. I got notified that gentoo removed the root cert of startssl, making TLS connections to nsupdate.info fail. We should use letsencrypt certificates.
kerem 2026-02-26 09:36:43 +03:00
  • closed this issue
  • added the
    task
    label
Author
Owner

@ThomasWaldmann commented on GitHub (Nov 21, 2016):

It's planned to move nsupdate.info service to a new server, but the precise date is unknown yet.

On that server, we'll also use letsencrypt certificates for nsupdate.info, if possible.

About gentoo's timing: it is known that startssl/wosign is on the way out, but until today I thought there is a gradual deprecation, first hitting all NEW certs (does not apply for us), then also the expiring certs (next year for us). So, gentoo was maybe a bit too quick / radical with this.

Workarounds for gentoo users might be:

  • install startssl root cert manually
  • using http to update IP
<!-- gh-comment-id:261990822 --> @ThomasWaldmann commented on GitHub (Nov 21, 2016): It's planned to move nsupdate.info service to a new server, but the precise date is unknown yet. On that server, we'll also use letsencrypt certificates for nsupdate.info, if possible. About gentoo's timing: it is known that startssl/wosign is on the way out, but until today I thought there is a gradual deprecation, first hitting all NEW certs (does not apply for us), then also the expiring certs (next year for us). So, gentoo was maybe a bit too quick / radical with this. Workarounds for gentoo users might be: - install startssl root cert manually - using http to update IP
Author
Owner

@bonki commented on GitHub (Nov 21, 2016):

Thanks for posting, we can continue this here :)

More specifically, it's ca-certificates-20160104.3.27.1-r2 which removed the StartCom and WoSign CAs from Gentoo unstable (bug #598072). The USE flag insecure_certs allows for them to be installed for now, i.e. if you trust the CAs something along the lines of

# echo "app-misc/ca-certificates insecure_certs" >/etc/portage/package.use/insecure-certs
# emerge ca-certificates

reinstalls all certificates and temporarily "fixes" the problem.

I agree that this was a hasty decision to make. Google and Mozilla provide more information on the matter and describe the actions they are taking here and here.

There is one paragraph (quoting Google) I don't really understand, though (emphasis mine):

Due to a number of technical limitations and concerns, Google Chrome is unable to trust all pre-existing certificates while ensuring our users are sufficiently protected from further misissuance. As a result of these changes, customers of WoSign and StartCom may find their certificates no longer work in Chrome 56.

The way I read it this means that even certificates issued before the cut-off date (October 21, 2016) might be subject to not being trusted in Chrome 56 any longer.

Obviously, I'd rather see us transition sooner than later.

<!-- gh-comment-id:262037189 --> @bonki commented on GitHub (Nov 21, 2016): Thanks for posting, we can continue this here :) More specifically, it's `ca-certificates-20160104.3.27.1-r2` which removed the StartCom and WoSign CAs from Gentoo unstable (bug [#598072](https://bugs.gentoo.org/show_bug.cgi?id=598072)). The `USE` flag `insecure_certs` allows for them to be installed for now, i.e. if you trust the CAs something along the lines of # echo "app-misc/ca-certificates insecure_certs" >/etc/portage/package.use/insecure-certs # emerge ca-certificates reinstalls all certificates and temporarily "fixes" the problem. I agree that this was a hasty decision to make. Google and Mozilla provide more information on the matter and describe the actions they are taking [here](https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html) and [here](https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/). There is one paragraph (quoting Google) I don't really understand, though (emphasis mine): > Due to a number of technical limitations and concerns, Google Chrome is unable to trust **all** pre-existing certificates while ensuring our users are sufficiently protected from further misissuance. As a result of these changes, customers of WoSign and StartCom may find their certificates no longer work in Chrome 56. The way I read it this means that even certificates issued *before* the cut-off date (October 21, 2016) might be subject to not being trusted in Chrome 56 any longer. Obviously, I'd rather see us transition sooner than later.
Author
Owner

@ThomasWaldmann commented on GitHub (Jan 20, 2017):

I just switched https://nsupdate.info/ service to a Let's Encrypt certificate, thus the cert problem is solved.

The server move is still pending, but will also happen soon.

<!-- gh-comment-id:274183454 --> @ThomasWaldmann commented on GitHub (Jan 20, 2017): I just switched https://nsupdate.info/ service to a Let's Encrypt certificate, thus the cert problem is solved. The server move is still pending, but will also happen soon.
Author
Owner

@ThomasWaldmann commented on GitHub (Jan 20, 2017):

As a side note:

We could not offer donations while using StartSSL for-free certificate (due to their very restrictive definition of non-commercial-only usage).

Thus I reenabled donations now, see the site footer.

<!-- gh-comment-id:274183648 --> @ThomasWaldmann commented on GitHub (Jan 20, 2017): As a side note: We could not offer donations while using StartSSL for-free certificate (due to their very restrictive definition of non-commercial-only usage). Thus I reenabled donations now, see the site footer.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/nsupdate.info-nsupdate-info#227
No description provided.