Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • N neutrinet_ynh
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 2
    • Issues 2
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • NeutrinetNeutrinet
  • neutrinet_ynh
  • Issues
  • #20
Closed
Open
Issue created Apr 25, 2020 by HgO@HgOOwner

Certificate renewal hotfix release

I already started some testing in !30 (merged)

In short, we have a bug that occurs when a certificate is renewed:

  • The common name (CN) was set to certificate for <email> before the refactoring of the renew_cert script last autumn.
  • Since we released the new script, the CN is now set to <email>
  • However, our VPN server doesn't like that kind of change, and can suddenly think that we introduced a new client with IPv6 only...

We are still not sure when this bug occurs exactly, but the fix is to take the CN from the VPN server. We first take the CN from the first IPv4 client, otherwise we take it from the first IPv6-only client, otherwise it is set to <email>.

We are waiting for the merge of renew_cert!3 (merged), but we could work on some improvement already. For instance, there will be new flags, such as --quiet that should be used in the cron job.

Edited Apr 26, 2020 by HgO
Assignee
Assign to
Time tracking