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