<div dir="ltr"><div>Hi,</div><div>Thanks again,</div><div><br></div><div>About your question :
so with the previous cert it worked but only because you had the verification set to false, correct?<span class="gmail-im"><br></span></div><div><span class="gmail-im">The answer is : Not exactly.</span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">Let me explain, I deployed using a commercial valid certificate, but I configured
kolla_verify_tls_backend to false exactly to avoid the problem I am facing now. From what I have understood :
kolla_verify_tls_backend=false, means : accept the connection even if the verification fails, but apparently it is not the case.</span></div><div><span class="gmail-im"></span></div><div><span class="gmail-im">And
kolla_copy_ca_into_containers was positioned to yes from the
beginning.</span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">What happened is that my certificate expired, and now I am searching for a way to install a self-signed certificate while waiting to get the new certificate.</span>
</div><div><br></div><div>I backported the platform a few days before the expiration of the certificate, then I generated the self-signed certificate and I tried to deploy it but without success.<br></div><div><br></div><div>Regards.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 14 nov. 2022 à 14:21, Eugen Block <<a href="mailto:eblock@nde.ag">eblock@nde.ag</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
> First I want to correct something, the *kolla_verify_tls_backend* was<br>
> positioned to *false* from the beginning, while doing the first deployment<br>
> with the commercial certificate.<br>
<br>
so with the previous cert it worked but only because you had the <br>
verification set to false, correct?<br>
<br>
> What do you mean by using openssl? Do you mean to execute the command<br>
> inside a container and try to connect to keystone? If yes what is the<br>
> correct command?<br>
<br>
That's one example, yes. Is apache configured correctly to use the <br>
provided certs? In my manual deployment it looks like this (only the <br>
relevant part):<br>
<br>
control01:~ # cat /etc/apache2/vhosts.d/keystone-public.conf<br>
[...]<br>
SSLEngine On<br>
SSLCertificateFile /etc/ssl/servercerts/control01.fqdn.cert.pem<br>
SSLCACertificateFile /etc/pki/trust/anchors/RHN-ORG-TRUSTED-SSL-CERT<br>
SSLCertificateKeyFile /etc/ssl/private/control01.fqdn.key.pem<br>
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown<br>
<br>
# HTTP Strict Transport Security (HSTS) enforces that all communications<br>
# with a server go over SSL. This mitigates the threat from attacks such<br>
# as SSL-Strip which replaces links on the wire, stripping away <br>
https prefixes<br>
# and potentially allowing an attacker to view confidential <br>
information on the<br>
# wire<br>
Header add Strict-Transport-Security "max-age=15768000"<br>
[...]<br>
<br>
and then test it with:<br>
<br>
---snip---<br>
control01:~ # curl -v <a href="https://control.fqdn:5000/v3" rel="noreferrer" target="_blank">https://control.fqdn:5000/v3</a><br>
[...]<br>
* ALPN, offering h2<br>
* ALPN, offering http/1.1<br>
* TLSv1.3 (OUT), TLS handshake, Client hello (1):<br>
* TLSv1.3 (IN), TLS handshake, Server hello (2):<br>
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):<br>
* TLSv1.3 (IN), TLS handshake, Certificate (11):<br>
* TLSv1.3 (IN), TLS handshake, CERT verify (15):<br>
* TLSv1.3 (IN), TLS handshake, Finished (20):<br>
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):<br>
* TLSv1.3 (OUT), TLS handshake, Finished (20):<br>
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384<br>
* ALPN, server accepted to use http/1.1<br>
* Server certificate:<br>
[...]<br>
* subjectAltName: host "control.fqdn" matched cert's "*.fqdn"<br>
* issuer: *******<br>
* SSL certificate verify ok.<br>
> GET /v3 HTTP/1.1<br>
> Host: control.fqdn:5000<br>
> User-Agent: curl/7.66.0<br>
> Accept: */*<br>
><br>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):<br>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):<br>
* old SSL session ID is stale, removing<br>
* Mark bundle as not supporting multiuse<br>
< HTTP/1.1 200 OK<br>
[...]<br>
* Connection #0 to host control.fqdn left intact<br>
{"version": {"id": "v3.14", "status": "stable", "updated": <br>
"2020-04-07T00:00:00Z", "links": [{"rel": "self", "href": <br>
"<a href="https://control.fqdn:5000/v3/" rel="noreferrer" target="_blank">https://control.fqdn:5000/v3/</a>"}], "media-types": [{"base": <br>
"application/json", "type": <br>
"application/vnd.openstack.identity-v3+json"}]}}<br>
---snip---<br>
<br>
To check the created certificate you could run something like this:<br>
<br>
openssl x509 -in /etc/ssl/servercerts/control01.fqdn.cert.pem -text -noout<br>
<br>
and see if the SANs match your control node(s) IP addresses and FQDNs.<br>
<br>
Zitat von wodel youchi <<a href="mailto:wodel.youchi@gmail.com" target="_blank">wodel.youchi@gmail.com</a>>:<br>
<br>
> Hi<br>
><br>
> Thanks for your help.<br>
><br>
> First I want to correct something, the *kolla_verify_tls_backend* was<br>
> positioned to *false* from the beginning, while doing the first deployment<br>
> with the commercial certificate.<br>
><br>
> And yes I have *kolla_copy_ca_into_containers* positioned to *yes* from the<br>
> beginning. And I can see in the nodes that there is a directory named<br>
> certificates in every module's directory in /etc/kolla<br>
><br>
> What do you mean by using openssl? Do you mean to execute the command<br>
> inside a container and try to connect to keystone? If yes what is the<br>
> correct command?<br>
><br>
> It seems like something is missing to tell the client side to ignore the<br>
> certificate validity, something like the --insecure parameter in the<br>
> openstack cli.<br>
><br>
> Regards.<br>
><br>
> On Fri, Nov 11, 2022, 21:21 Eugen Block <<a href="mailto:eblock@nde.ag" target="_blank">eblock@nde.ag</a>> wrote:<br>
><br>
>> Hi,<br>
>><br>
>> I'm not familiar with kolla, but the docs also mention this option:<br>
>><br>
>> kolla_copy_ca_into_containers: "yes"<br>
>><br>
>> As I understand it the CA cert is required within the containers so<br>
>> they can trust the self-signed certs. At least that's how I configure<br>
>> it in a manually deployed openstack cloud. Do you have that option<br>
>> enabled? If it is enabled, did you verify it with openssl tools?<br>
>><br>
>> Regards,<br>
>> Eugen<br>
>><br>
>> Zitat von wodel youchi <<a href="mailto:wodel.youchi@gmail.com" target="_blank">wodel.youchi@gmail.com</a>>:<br>
>><br>
>> > Some help please.<br>
>> ><br>
>> > On Tue, Nov 8, 2022, 14:44 wodel youchi <<a href="mailto:wodel.youchi@gmail.com" target="_blank">wodel.youchi@gmail.com</a>> wrote:<br>
>> ><br>
>> >> Hi,<br>
>> >><br>
>> >> To deploy Openstack with a self-signed certificate, the documentation<br>
>> says<br>
>> >> to generate the certificates using kolla-ansible certificates, to<br>
>> configure<br>
>> >> the support of TLS in globals.yml and to deploy.<br>
>> >><br>
>> >> I am facing a problem, my old certificate has expired, I want to use a<br>
>> >> self-signed certificate.<br>
>> >> I backported my servers to an older date, then generated a self-signed<br>
>> >> certificate using kolla, but the deploy/reconfigure won't work, they<br>
>> say :<br>
>> >><br>
>> >> self._sslobj.do_handshake()\n File \"/usr/lib64/python3.6/ssl.py\",<br>
>> line<br>
>> >> 648, in do_handshakeself._sslobj.do_handshake()\nssl.SSLError: [SSL:<br>
>> >> CERTIFICATE_VERIFY_FAILED certificate verify failed<br>
>> >><br>
>> >> PS : in my globals.yml i have : *kolla_verify_tls_backend: "yes"*<br>
>> >><br>
>> >> Regards.<br>
>> >><br>
>><br>
>><br>
>><br>
>><br>
>><br>
<br>
<br>
<br>
</blockquote></div>