### Problem to solve <!-- What problem do we solve? --> Applications that serve traffic using invalid or expired certificates mean that end-users can't be sure if they're talking to the real application or an imposter. This means that they will not know when an attacker is intercepting their connection and will trust the application less. It is difficult to know when an application's certificates have expired or are not valid until after the fact without requiring manual work. A recent example of the need for this capability is the [recent outage of Teams](https://arstechnica.com/gadgets/2020/02/yesterdays-multi-hour-teams-outage-was-due-to-an-expired-ssl-certificate/?amp=1) being caused by expired SSL certificates. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> This should be applicable for users who are using GitLab to deploy and manage their applications, not pointing to 3rd-party sites. We shouldn't intentionally exclude 3rd-party sites, but we don't need to focus on them specifically for this issue. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Periodically check the certificates that are being used to serve traffic for a user's application hosted with GitLab. This should not need to be triggered in a pipeline by a code commit, as scanning should be performed even if users take no action after initially configuring the SSL certificate checking. If the certificates are invalid or expired, notify the user so they can then manually take action. This should be done at a minimum with a new screen that users can navigate to. Evaluate if there are also other ways we could notify users. #### Minimal requirements to make the MVC Viable 1. [Provide users a way to enable TLS/SSL monitoring for a GitLab-hosted application.](https://gitlab.com/gitlab-org/gitlab/issues/205318) 1. [Periodically run a scan on the given URLs to check the status of their certificates](https://gitlab.com/gitlab-org/gitlab/issues/205319) 1. [Provide notice to users if a certificate is invalid or expired.](https://gitlab.com/gitlab-org/gitlab/issues/205321) 1. [Usage ping implemented to record feature usage](https://gitlab.com/gitlab-org/gitlab/issues/205322) #### UX 1. Scanning should happen periodically without requiring a user to manually trigger the scan. Scanning should also not require a code commit nor an MR. * *Coordinate with UX on designs for this screen* * Some initial concepts are attached under the Design tab #### Future work ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> To view the report & controls, users should have the same permissions as are required to view the Security Dashboard. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> Create documentation to show users how to enable the settign for their projects as well as how to view and interpret the results. Add a section that describes how to remedy the most common problematic situations related to their certificates (expiration, invalid signature) ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> We can measure how many URLs are monitored with SSL monitoring (Target => 5000 in first 3 months) * This will ensure that the feature provides enough value to be useful. We can measure how many unique repos are using the capability (Target => 3000 in first 3 months) * This will ensure that the feature solves the most common use and isn't missing critical edge cases. ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ~"GitLab Ultimate" ### Links / references * [Problem validation issue](gitlab#202318) * [Sidekiq scheduled jobs](https://docs.gitlab.com/ee/development/sidekiq_style_guide.html#cron-workers) * [Example of year-old expired certs being a problem, rather than the appliance](https://twitter.com/threatresearch/status/1226957874502332416)