Skip to content

[WIP] Update Ursulas certificate#2700

Closed
piotr-roslaniec wants to merge 1 commit intonucypher:mainfrom
piotr-roslaniec:update-cert#2674
Closed

[WIP] Update Ursulas certificate#2700
piotr-roslaniec wants to merge 1 commit intonucypher:mainfrom
piotr-roslaniec:update-cert#2674

Conversation

@piotr-roslaniec
Copy link
Copy Markdown
Contributor

@piotr-roslaniec piotr-roslaniec commented May 18, 2021

Type of PR:

  • Bugfix
  • Feature
  • Documentation
  • Other

Required reviews:

  • 1
  • 2
  • 3

What this does:

High-level idea of the changes introduced in this PR.
List relevant API changes (if any), as well as related PRs and issues.

Issues fixed/closed:

Why it's needed:

Explain how this PR fits in the greater context of the NuCypher Network.
E.g., if this PR address a nucypher/productdev issue, let reviewers know!

Notes for reviewers:

  • This PR will be heavily rewritten

self.log.warn(f"Replaced SSL certificate for host: {host}")
except:
self.log.warn(f"Failed to replace SSL certificate for host: {host}")
pass
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What exceptions are you anticipating here? Do you think it will be okay to suppress all of them?

Copy link
Copy Markdown
Contributor Author

@piotr-roslaniec piotr-roslaniec May 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clarify, this PR is not in its intended state, and the exceptions should be handled on a case-to-case basis. I'm probably going to take a different approach in solving this issue and this PR will be heavily rewritten.

@KPrasch
Copy link
Copy Markdown
Member

KPrasch commented Jun 15, 2021

This PR is on my mind today - I think adopting the principal of "always replace" the TLS certificate is the most simple and elegant way to ensure that the cert always matches the latest remote node's runtime, regardless of state changes, restarts, rederivation of keys, etc.

@derekpierre
Copy link
Copy Markdown
Member

This PR is on my mind today - I think adopting the principal of "always replace" the TLS certificate is the most simple and elegant way to ensure that the cert always matches the latest remote node's runtime, regardless of state changes, restarts, rederivation of keys, etc.

@KPrasch , @piotr-roslaniec any thoughts on #2674 (comment)? It isn't an "always replace" solution but a "check and replace" solution.

@piotr-roslaniec
Copy link
Copy Markdown
Contributor Author

An attempt to sum up our discussion:

  1. On server-side - Check and replace your own certificate during startup
  2. On client-side - Check and replace server certificate on every connection

I think these two combined cover all relevant cases.

On a different note, should "1)" be enabled by default? Or should the node just fail on startup? In case someone uses a regular certificate (not self-signed).

@derekpierre
Copy link
Copy Markdown
Member

derekpierre commented Aug 18, 2021

Or should the node just fail on startup?

If we do that, would we basically have to provide some tool for users to generate their own cert? Feels like it, since the situation would need to be resolved somehow.

In case someone uses a regular certificate (not self-signed).

Possible but seems highly unlikely to me since I think (?) they would have to muck with the files nucypher produced and possibly the code...

@piotr-roslaniec piotr-roslaniec deleted the update-cert#2674 branch September 6, 2021 20:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

How does an Ursula update their TLS certificate if eg. the IP address changes

3 participants