N1C CSG unmanaged certificates #1597
Conversation
github-actions
bot
added
documentation
✅ Deploy Preview will be available once build job completes!
|
|
@sylwang overall, this is excellent. I plan to comment on a few details. But first, a "big picture" question. I know that you can have unmanaged certs with an instance. I'm tempted to recommend moving unmanaged-certificates.md to the content/nginx-one-console/nginx-configs/certificates directory |
|
|
||
| Unmanaged certificates are SSL/TLS certificates that you install and manage manually on NGINX instances. Unlike managed certificates that are uploaded and distributed through the NGINX One Console, unmanaged certificates are installed directly on individual instances and referenced by their file paths in NGINX configuration files. You are responsible for distributing, updating, and maintaining these certificates across your infrastructure. | ||
|
|
||
| ### Unmanaged certificates in Config Sync Groups |
There was a problem hiding this comment.
Markdown format rule (look up MD022)
| ### Unmanaged certificates in Config Sync Groups | |
| ### Unmanaged certificates in Config Sync Groups | |
| Unmanaged certificates are SSL/TLS certificates that you install and manage manually on NGINX instances. Unlike managed certificates that are uploaded and distributed through the NGINX One Console, unmanaged certificates are installed directly on individual instances and referenced by their file paths in NGINX configuration files. You are responsible for distributing, updating, and maintaining these certificates across your infrastructure. | ||
|
|
||
| ### Unmanaged certificates in Config Sync Groups | ||
| Config Sync Groups (CSGs) in NGINX One Console ensure configuration consistency across connected NGINX instances. While managed certificates uploaded through the Console are automatically synchronized and tracked, unmanaged certificates follow a different model that provides visibility without automated management. |
There was a problem hiding this comment.
Moving phrase to the start of the next paragraph.
| Config Sync Groups (CSGs) in NGINX One Console ensure configuration consistency across connected NGINX instances. While managed certificates uploaded through the Console are automatically synchronized and tracked, unmanaged certificates follow a different model that provides visibility without automated management. | |
| Config Sync Groups (CSGs) in NGINX One Console ensure configuration consistency across connected NGINX instances. While managed certificates uploaded through the Console are automatically synchronized and tracked, unmanaged certificates follow a different model. |
| When you use unmanaged certificates in a CSG, NGINX One Console does not synchronize the certificate files themselves. However, it tracks their metadata to help you verify consistency across instances and understand the state of your certificates. | ||
|
|
||
| ## How unmanaged certificates work in Config Sync Groups | ||
|
|
There was a problem hiding this comment.
Suggestion (not a requirement): add an intro to the subsections that follow:
| If you have unmanaged certificates with CSGs, consider the following factors: | |
|
|
||
| ## Requirements for unmanaged certificates | ||
|
|
||
| To use unmanaged certificates effectively in Config Sync Groups, you must: |
There was a problem hiding this comment.
| To use unmanaged certificates effectively in Config Sync Groups, you must: | |
| To use unmanaged certificates effectively in Config Sync Groups, you must address these issues: |
| - **User responsibility**: Take full responsibility for certificate distribution, updates, and consistency | ||
|
|
||
| ## Important considerations | ||
|
|
There was a problem hiding this comment.
| NGINX One Console still helps you track unmanaged certificates: | |
|
|
||
| If certificate file paths differ between instances: | ||
|
|
||
| - CSG publication may fail |
There was a problem hiding this comment.
Just checking. Is it CSG or certificate publication that can fail?
There was a problem hiding this comment.
If it is CSG publication that can fail, I'd change current line 44 (comment added there)
| ### Synchronization limitations | ||
|
|
||
| - **No automated sync**: Unmanaged certificates are not synchronized by the Console | ||
| - **Manual updates**: You must manually update certificates on each instance when they expire or need rotation |
There was a problem hiding this comment.
For consistency:
| - **Manual updates**: You must manually update certificates on each instance when they expire or need rotation | |
| - **Manual updates**: Certificates must be manually updated on each instance |
|
|
||
| Monitor the **Config Sync Status** column. It can help you ensure that your configurations are consistently applied across all instances in a group. | ||
|
|
||
| ## Working with unmanaged certificates |
There was a problem hiding this comment.
We avoid gerunds (-ing words) in section titles. Exception: troubleshooting
| ## Working with unmanaged certificates | |
| ## Work with unmanaged certificates |
| - Certificates are identified by their content and associated instance | ||
| - The CSG displays separate certificate entries in the configuration | ||
|
|
||
| If certificate file paths differ between instances: |
There was a problem hiding this comment.
If it's actually CSG publication that may fail, I suggest revising this to:
| If certificate file paths differ between instances: | |
| If certificates are identical, but their file paths differ by instance: |
|
|
||
| ### Certificate inconsistencies | ||
|
|
||
| If you see multiple entries for what should be the same certificate: |
There was a problem hiding this comment.
I see you've numbered these options. In general, I number steps when users have to do them, in order.
If ordering is not required, I'd replace the numbers with bullets
|
FYI, I'll be working Dec 22, 23, 29, 30, 31. I might be the only writer available during these days -- and I have no problem merging on my own, once we've addressed these suggestions. |
Proposed changes
Checklist
Before sharing this pull request, I completed the following checklist:
Footnotes
Potentially sensitive information includes personally identify information (PII), authentication credentials, and live URLs. Refer to the style guide for guidance about placeholder content. ↩