Open Stack

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 at 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 at 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 at 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 at gmail.com>:
> >>
> >> > Some help please.
> >> >
> >> > On Tue, Nov 8, 2022, 14:44 wodel youchi <wodel.youchi at 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.
> >> >>
> >>
> >>
> >>
> >>
> >>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20221114/1487f379/attachment.htm>