First published: Mon May 02 2022(Updated: )
A re-encrypt Route with destinationCACertificate explicitly set to the default serviceCA seems to skip internal Service TLS certificate validation, errorless serving content even if target Service certificate and certificate provided by target Pod(s) differ. Note that if we don't set destinationCACertificate in the Route yaml manifest (the Route will still implicitly use the same default serviceCA certificate, as described on the doc [1]) we will correctly get a error page. References: <a class="bz_bug_link bz_secure " title="" href="show_bug.cgi?id=2041857">https://bugzilla.redhat.com/show_bug.cgi?id=2041857</a>
Credit: secalert@redhat.com
Affected Software | Affected Version | How to fix |
---|---|---|
Redhat Ansible Automation Platform | =2.0 | |
Redhat Openshift Container Platform | =4.0 | |
Fedoraproject Fedora | =34 | |
Fedoraproject Fedora | =35 |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.
The vulnerability ID is CVE-2022-1632.
The severity of CVE-2022-1632 is medium (6.5).
The affected software includes Redhat Ansible Automation Platform 2.0, Redhat Openshift Container Platform 4.0, Fedoraproject Fedora 34, and Fedoraproject Fedora 35.
CVE-2022-1632 allows an attacker to exploit an invalid certificate, resulting in a loss of confidentiality.
Yes, you can find references for CVE-2022-1632 at the following Bugzilla links: [Bugzilla 2041857](https://bugzilla.redhat.com/show_bug.cgi/show_bug.cgi?id=2041857), [Bugzilla 2083320](https://bugzilla.redhat.com/show_bug.cgi/show_bug.cgi?id=2083320), [Bugzilla 2083321](https://bugzilla.redhat.com/show_bug.cgi/show_bug.cgi?id=2083321).