Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TLS] Check if provided certificate is valid #16762

Closed
tolusha opened this issue Apr 27, 2020 · 2 comments
Closed

[TLS] Check if provided certificate is valid #16762

tolusha opened this issue Apr 27, 2020 · 2 comments
Assignees
Labels
area/install Issues related to installation, including offline/air gap and initial setup kind/task Internal things, technical debt, and to-do tasks to be performed. severity/P1 Has a major impact to usage or development of the system.

Comments

@tolusha
Copy link
Contributor

tolusha commented Apr 27, 2020

Is your task related to a problem? Please describe.

If invalid certificate was used then Eclipse Che deployed fail.
It is better to add preflight check and warn an user.

Describe the solution you'd like

Add basic check for the certificate:

  • due date
  • domain
@tolusha tolusha added kind/task Internal things, technical debt, and to-do tasks to be performed. severity/P1 Has a major impact to usage or development of the system. area/install Issues related to installation, including offline/air gap and initial setup labels Apr 27, 2020
@tolusha tolusha added this to the Backlog - Deploy milestone Apr 27, 2020
@tolusha tolusha changed the title Check if provided certificate is valid [TLS] Check if provided certificate is valid May 6, 2020
@tolusha tolusha mentioned this issue May 8, 2020
56 tasks
@mmorhun mmorhun self-assigned this May 18, 2020
@mmorhun
Copy link
Contributor

mmorhun commented May 19, 2020

I've taken a quick look at this issue.
Here we need to consider various aspects before complete implementation of the problem.
The steps, which I think, we should take:
Check cluster family.

  • If it is Kubernetes then:

    1. Check if the certificate is present. If not, just skip this check and a valid certificate will be generated automatically.
    2. If a certificate is present (self-signed (or signed by self-signed CA) or not) we should read it and analyze at least basic requirements:
      • check that certificate domain is suitable for our cluster
      • check that certificate due dates are ok (not before, not after).
  • If it is Openshift family, we reuse router certificate for Che endpoints securing. We may check router certificate in two ways:

    1. If we have cluster admin rights, we might read the router certificate and follow instruction as described in step 2 for Kubernetes platform.
    2. If we don't have cluster admin rights, the only way to check is to create a simple server and expose its endpoint via a route and then try to query it. Here we have to be careful to not to distrust self-signed certificates immediately. We need to do deeper analyzation with steps described in Kubernetes flow (the difference is that the certificate is obtained via query, not from the secret).

We may try to generalize the solution by creating a simple server with exposing ingress/route and the analyze the certificate in the identical way. This brings unneeded complexity for pure Kubernetes infras, but gives us a single way of resolving the problem.

I've quickly looked at the certificate analyzation problem and may say that we definitely need to use some library to parse certificates (Often they have C++ backend with Nodejs bindings). One of such libs for Nodejs is node-x509. With help of it I was able to decode the certificate and see its fields.

P.S. As we've already implemented autogeneration of TLS certificates for Che installation this issue isn't urgent any more as it is applicable only if user wants to provide own certificates for Che installation instead of using generated by Che one.

@tolusha tolusha mentioned this issue May 22, 2020
7 tasks
@tolusha tolusha removed this from the Backlog - Deploy milestone May 27, 2020
@che-bot
Copy link
Contributor

che-bot commented Jan 4, 2021

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 4, 2021
@che-bot che-bot closed this as completed Jan 20, 2021
@mmorhun mmorhun removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/install Issues related to installation, including offline/air gap and initial setup kind/task Internal things, technical debt, and to-do tasks to be performed. severity/P1 Has a major impact to usage or development of the system.
Projects
None yet
Development

No branches or pull requests

3 participants