Open Stack

Okay, I understand. Did you verify if the self-signed cert contains  
everything you require as I wrote in the previous email? Can you paste  
the openssl command output (and mask everything non-public)?

Zitat von wodel youchi <wodel.youchi at gmail.com>:

> 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.
>> >> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>>
>>
>>
>>