| Anonymous | Login | 2024-11-21 04:15 MST |
| Main | My View | View Issues | Change Log | Roadmap | Repositories |
| View Revisions: Issue #19021 | [ All Revisions ] [ Back to Issue ] | ||
| Summary | 0019021: Create smart widget for external HTTPS links | ||
| Revision | 2018-02-02 16:10 by user2 | ||
| Description | ClearOS often links to external UIs, e.g.: - phpMyAdmin - ClearGLASS - CUPS - Openfire The problem: the nasty certificate error shown in the web browser. Openfire was the first app that provided a widget that provides some integration into Let's Encrypt. The external link to Openfire in the ClearOS UI now points to the secure link, e.g. https://openfire.example.com:9091 [^] instead of https://192.168.1.100:9091. [^] Benefit: better usability for the end user ... no more nasty certificate errors in the browser! However, there are some of gotchas that need to be addressed: - Chrome seems to cache the HTTPS connection. If the underlying certificate is changed, a new browser session is needed in order to see the new certificate. Is there a way around this? HTTP headers? - There's no guarantee the hostname provided in the secure certificate is pointing to the ClearOS server. For Let's Encrypt, it's a relatively safe assumption since it would have been a requirement to create the SSL certificate. The assumption might not hold for 3rd party certificates. - Wildcard certificates are not handled in the Openfire implementation. - The current widget shows the self-signed certificate. Users will often not bother importing this certificate so they will continue to see the browser warning. Should we require Let's Encrypt for apps with external links? And then hide the self-signed option? |
||
| Revision | 2018-02-02 15:49 by user2 | ||
| Description | ClearOS often links to external UIs, e.g.: - phpMyAdmin - ClearGLASS - CUPS - Openfire The problem: the nasty certificate error shown in the web browser. Openfire was the first app that provided a widget that provides some integration into Let's Encrypt. The external link to Openfire in the ClearOS UI now points to the secure link, e.g. https://openfire.example.com:9091 [^] instead of https://192.168.1.100:9091. [^] Benefit: better usability for the end user ... no more nasty certificate errors in the browser! However, there are some of gotchas that need some refinement. - Chrome seems to cache the HTTPS connection. If the underlying certificate is changed, a new browser session is needed in order to see the new certificate. Is there a way around this? HTTP headers? - There's no guarantee the hostname provided in the secure certificate is pointing to the ClearOS server. For Let's Encrypt, it's a relatively safe assumption since it would have been a requirement to create the SSL certificate. The assumption might not hold for 3rd party certificates. - Wildcard certificates are not handled in the Openfire implementation. |
||