Issues
- PMMv3 renew self signed certificatesPMM-9109talha.rizwan
- postgres_exporter does not report 0 when postgres is down.PMM-9015Resolved issue: PMM-9015
- Error when adding Amazon RDS MySQL with TLS over APIPMM-8014Resolved issue: PMM-8014Jiří Čtvrtka
- Inconsistent format of version reporting in pmm-adminPMM-7939Resolved issue: PMM-7939
- Enable configuration update via the APIPMM-6833
- Enable configuration verification via APIPMM-6832
- Add service datadir as a path in metricsPMM-6195
- News panel does not work in fully isolated from internet environmentPMM-6154Resolved issue: PMM-6154Maksym Hilliaka
- PMM 2.7.0 inoperable when no Internet connectivityPMM-6153Resolved issue: PMM-6153
- pmm-admin does not use 'listen-port' value from the agent config filePMM-5831Resolved issue: PMM-5831Jiří Čtvrtka
- MySQL Table Statistics - disable automaticallyPMM-4937Resolved issue: PMM-4937
- PMM Server access credentials are shown by the pmm-admin status command instead of hiding them for security reasonsPMM-4876Resolved issue: PMM-4876
- Restore options that have been removed for pmm-admin (host, port) + new one (name)PMM-4846Resolved issue: PMM-4846
- Allow PMM server configuration capability for automatic disabling of MySQL Table StatisticsPMM-4799Resolved issue: PMM-4799
- MySQL Table Statistics - make it configurablePMM-4535Resolved issue: PMM-4535
- Provide basic RDS MySQL monitoringPMM-3444Resolved issue: PMM-3444
- The PMM Server API (via /v1/readyz) now also returns Grafana status information in addition to that for Prometheus.PMM-1962Resolved issue: PMM-1962
PMMv3 renew self signed certificates
Description
How to test
Refinement notes
get use old pmm certificate, restart pmm and check for certificate update + custom user cert was not replaced / affected
How to document
would be great to warn users to not to use our certs in PROD
Smart Checklist
Activity
Roma Novikov November 6, 2024 at 10:42 AM
Since this issue wasn’t resolved before PMM v3 and we do not anticipate it being a major problem in v3—given that there will be no package update method making this issue more significant—we will keep it on record for now. It still needs to be reviewed, as more problems may be discovered.
Ananias Tsalouchidis November 8, 2021 at 12:34 PM
Hello @Roma Novikov and thanks for taking a look.
Self signed certs should ideally not being used so It's mostly "make self-signed more correct". This is also kind of a good impression as leaving certs to expire does not seem nice.
There is no blocker but since agents talk to the server over encrypted channels that would be good to have an active cert even if self signed.
Using expired certs also causes some noise as security tools may report the PMM instance as vulnerable because it is using an expired cert - assuming that self signed are accepted - (this is how it all started).
Thanks,
Ananias.
Roma Novikov November 8, 2021 at 12:19 PM
Hi @Ananias Tsalouchidis
Can you explain the problem from the user's side? Are the users affected?
I've tested mentioned scenario and can't see the problem( as at first place I'm "accepting an insecure connection," so we let PMM work with "whatever the certificate we have."
I'm trying to understand if this request is about "make self-signed more correct" or there are some problems to users already, and we need to solve them faster?
User story:
As an Admin installed PMM, I need to have "more correct" certificates inside PMM, so they are self-signed but do not cause an additional warning by security tools because they are outdated
UI/UX:
N/A
Acceptance criteria
Installed or updated version of PMM always have not-expired self-signed sertificates
A special precaution should be taken not to replace the public certificate the user may have mounted to
/srv/nginx/
directory;Out of scope:
UI for certificate management
Integration with let's encrypt or related service
Suggested implementation:
TBD
How to test:
TBD
Details:
TBD
For testing purposes, I've installed through docker PMM v. 2.11.0 which was released back in Oct 2020.
https://www.percona.com/doc/percona-monitoring-and-management/2.x/release-notes/2.11.0.html
This is what the self signed certificate was reporting as an expiration date
[centos@ip-192-168-2-206 ~]$ echo -n | openssl s_client -connect 127.0.0.1:443 | openssl x509 -noout -dates depth=0 O = Main Org. verify error:num=18:self signed certificate verify return:1 depth=0 O = Main Org. verify error:num=10:certificate has expired notAfter=Oct 14 16:50:17 2021 GMT verify return:1 depth=0 O = Main Org. notAfter=Oct 14 16:50:17 2021 GMT verify return:1 DONE notBefore=Oct 14 16:50:17 2020 GMT notAfter=Oct 14 16:50:17 2021 GMT
so it appears that certificate is valid for 365 days only.
I've then performed an upgrade through the UI from 2.11.0 to 2.23.0
2.23.0 was released on Oct 2021
https://www.percona.com/doc/percona-monitoring-and-management/2.x/release-notes/2.23.0.html
Checking the certificate again it seems that this was not renewed
[centos@ip-192-168-2-206 ~]$ echo -n | openssl s_client -connect 127.0.0.1:443 | openssl x509 -noout -dates depth=0 O = Main Org. verify error:num=18:self signed certificate verify return:1 depth=0 O = Main Org. verify error:num=10:certificate has expired notAfter=Oct 14 16:50:17 2021 GMT verify return:1 depth=0 O = Main Org. notAfter=Oct 14 16:50:17 2021 GMT verify return:1 DONE notBefore=Oct 14 16:50:17 2020 GMT notAfter=Oct 14 16:50:17 2021 GMT
I would expect / suggest:
Default certificates to get auto-renewed if these are going to expire (even without an upgrade)
Default certificates to be replaced when an upgrade happens