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

nginx: separate cert paths from server_name #814

Merged
merged 1 commit into from
Dec 7, 2024

Conversation

alxndrsn
Copy link
Contributor

@alxndrsn alxndrsn commented Dec 3, 2024

Working on #809 I noticed that the location of SSL certs is based either on the domain name, or on the method of supply of SSL certs.

Cert provision approach should probably not affect the nginx "server_name" setting.

Also, the old variable name CNAME (short for "certificate name?") is easily confused with the DNS concept of CNAME records ("canonical names") (https://en.wikipedia.org/wiki/CNAME_record).

What has been done to verify that this works as intended?

Ran tests.

Why is this the best possible solution? Were any other approaches considered?

It may not be - there may be a subtle reason for the current use and/or naming of CNAME.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Behaviour that may have accidentally been affected:

Servers with SSL_TYPE = "customssl" may have their nginx server_name changed. This is probably a positive change - currently it has no effect, but will do once #809 is merged.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

It should not.

Before submitting this PR, please make sure you have:

  • branched off and targeted the next branch OR only changed documentation/infrastructure (master is stable and used in production)
  • verified that any code or assets from external sources are properly credited in comments or that everything is internally sourced

Working on getodk#809 I noticed that the location of SSL certs is based either on the domain name, or on the method of supply of SSL certs.

Cert provision approach should probably not affect the nginx "server_name" setting.

Also, the old variable name `CNAME` (short for "certificate name?") is easily confused with the DNS concept of CNAME records ("canonical names").
@alxndrsn alxndrsn requested a review from yanokwa December 3, 2024 06:43
@alxndrsn alxndrsn marked this pull request as ready for review December 3, 2024 06:46
alxndrsn pushed a commit to alxndrsn/odk-central that referenced this pull request Dec 3, 2024
@alxndrsn alxndrsn requested a review from brontolosone December 6, 2024 06:38
Copy link
Contributor

@brontolosone brontolosone left a comment

Choose a reason for hiding this comment

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

Makes sense!
I, for one, was confused by seeing the term CNAME.

@alxndrsn
Copy link
Contributor Author

alxndrsn commented Dec 6, 2024

CNAME was first used for server_name in baa828b (cc @yanokwa)

@brontolosone
Copy link
Contributor

at the time, I cursorily concluded "they probably call it cname as it's maybe DNS CNAMEs with which they do vanity domains for cloud ODK or somesuch so at some point it made sense to call this variable cname as it's where the cname record's label happened to go" 😆

Copy link
Member

@yanokwa yanokwa left a comment

Choose a reason for hiding this comment

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

I don't know why I called it CNAME. The change looks good to me.

@alxndrsn
Copy link
Contributor Author

alxndrsn commented Dec 7, 2024

I don't know why I called it CNAME. The change looks good to me.

You didn't introduce the original CNAME variable - that came from @issa-tseng in 9b972e7.

@alxndrsn alxndrsn merged commit 515bfb9 into getodk:next Dec 7, 2024
2 checks passed
@alxndrsn alxndrsn deleted the rename-cert-domain-domain branch December 7, 2024 11: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.

3 participants