Bug 1994179
| Summary: | Cannot log into Migration Tool for Virtualization (Forklift); "Authentication failed" issue reported | ||
|---|---|---|---|
| Product: | Migration Toolkit for Virtualization | Reporter: | kevin <welin> |
| Component: | Operator | Assignee: | Fabien Dupont <fdupont> |
| Status: | CLOSED ERRATA | QA Contact: | Amos Mastbaum <amastbau> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 2.0.0 | CC: | apinnick, fbladilo, fdupont, istein, nijoshi, rhoch |
| Target Milestone: | --- | ||
| Target Release: | 2.3.0 | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-04-04 18:03:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
I've have checked in Kevin's lab and seen the following. The error message in the UI pod log is "Access Token Error Client request error: unable to verify the first certificate". The "Access Token Error" message comes from deploy/server.js when calling getClusterAuth. This method is defined in deploy/oAuthHelpers.js and calls getOAuthMeta that either returns a cached authentication or calls https://{meta.clusterApi}/.well-known/oauth-authorization-server. Since it doesn't have a cached token, it calls the URL. The full URL is https://oauth-openshift.apps.cluster.example.com/oauth/authorize, which is exposed by a route, hence uses the custom wildcard certificate. From inside the UI pod, the following command shows that the certificate chain is broken, even when using /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt as the CA bundle. $ openssl s_client -showcerts -servernameoauth-openshift.apps.cluster.example.com -connect oauth-openshift.apps.cluster.example.com:443 --CAfile /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt </dev/null CONNECTED(00000003) depth=0 C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = *.apps.cluster.example.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = *.apps.cluster.example.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = *.apps.cluster.example.com i:C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = ca.cluster.example.com -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- --- Server certificate subject=C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = *.apps.cluster.example.com issuer=C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = ca.cluster.example.com --- Acceptable client certificate CA names OU = openshift, CN = admin-kubeconfig-signer OU = openshift, CN = kube-control-plane-signer OU = openshift, CN = kube-apiserver-to-kubelet-signer OU = openshift, CN = kubelet-bootstrap-kubeconfig-signer CN = openshift-kube-apiserver-operator_node-system-admin-signer@1628658629 CN = openshift-kube-controller-manager-operator_csr-signer-signer@1628727187 CN = kube-csr-signer_@1628727297 CN = openshift-kube-apiserver-operator_aggregator-client-signer@1628727193 Requested Signature Algorithms: RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA384:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1 Shared Requested Signature Algorithms: RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA384:ECDSA+SHA512 Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 2934 bytes and written 461 bytes Verification error: unable to verify the first certificate --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 4096 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 21 (unable to verify the first certificate) --- DONE The following command lists the Subject of all the certificates in the /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt CA bundle. $ openssl crl2pkcs7 -nocrl -certfile /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt | openssl pkcs7 -print_certs -text -noout | grep 'Subject:' Subject: OU=openshift, CN=kube-apiserver-lb-signer Subject: OU=openshift, CN=kube-apiserver-localhost-signer Subject: OU=openshift, CN=kube-apiserver-service-network-signer Subject: CN=openshift-kube-apiserver-operator_localhost-recovery-serving-signer@1628658629 Subject: C=CN, ST=Beijing, L=Beijing, O=REDHAT, OU=SA, CN=*.apps.cluster.example.com Subject: CN=openshift-service-serving-signer@1628658618 We can see that the certificate for the OAuth endpoint exposed by the ingress router is present with subject "C=CN, ST=Beijing, L=Beijing, O=REDHAT, OU=SA, CN=*.apps.cluster.example.com". However, we can see in the full certificate validation that it is signed by "C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = ca.cluster.example.com", and the certificate for this CA is missing. This explains the error message "unable to verify the first certificate" that we see in the UI pod log. According to OpenShift 4.7 documentation [1]: "The certificate file can contain one or more certificates in a chain. The wildcard certificate must be the first certificate in the file. It can then be followed with any intermediate certificates, and the file should end with the root CA certificate." The procedure also shows that a dedicated ConfigMap with custom CA bundle must be created. Patching the ingress controller is not enough. From my workstation, the following command confirms that the CA chain is broken also for the OpenShift Console: $ openssl s_client -showcerts -servername console-openshift-console.apps.cluster.example.com -connect console-openshift-console.apps.cluster.example.com:443 </dev/null CONNECTED(00000003) depth=0 C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = *.apps.cluster.example.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = *.apps.cluster.example.com verify error:num=21:unable to verify the first certificate verify return:1 depth=0 C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = *.apps.cluster.example.com verify return:1 --- Certificate chain 0 s:C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = *.apps.cluster.example.com i:C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = ca.cluster.example.com -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- --- Server certificate subject=C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = *.apps.cluster.example.com issuer=C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = ca.cluster.example.com --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 2314 bytes and written 437 bytes Verification error: unable to verify the first certificate --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 4096 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 21 (unable to verify the first certificate) --- DONE [1] https://docs.openshift.com/container-platform/4.7/security/certificates/replacing-default-ingress-certificate.html Hello
I have reproduce you reply issue. The root cause is your client PC without trust the ingress's root CA certificate.
Because we have set the OCP default ingress certificate as company sign private certificate which sign by company private root CA, which you must trust them in your client PC
I have provide my rootCA certificate for you in slack
======================================================
The following is my reprodece result:
======================================================
------------------------------------------------------
(1) The Client PC without install the ingress certificate related root CA certificate
------------------------------------------------------
The result tell me : Verify return code: 21 (unable to verify the first certificate), This result is same as your report
# openssl s_client -showcerts -servername console-openshift-console.apps.cluster0.xxxx.opentlc.com -connect console-openshift-console.apps.cluster0.xxxx.opentlc.com:443
CONNECTED(00000003)
depth=0 C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = *.apps.cluster0.xxxx.opentlc.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = *.apps.cluster0.xxxx.opentlc.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=CN/ST=Beijing/L=Beijing/O=REDHAT/OU=SA/CN=*.apps.cluster0.sandbox1532.opentlc.com
i:/C=CN/ST=Beijing/L=Beijing/O=REDHAT/OU=SA/CN=ca.cluster0.sandbox1532.opentlc.com
-----BEGIN CERTIFICATE-----
MIIF1jCCA76gAwIBAgIJAPZPYSdAolnlMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNV
BAYTAkNOMRAwDgYDVQQIDAdCZWlqaW5nMRAwDgYDVQQHDAdCZWlqaW5nMQ8wDQYD
......
8UWRMj7/NWbotPqkNEhjy2BdDGcImGC8eQDAA2mlHHo1YXI/816sNTsq6BTz3XyH
kiA7AFjWkzefA+gZbxZC51GUqOrQVKo3zj8oN4tLmXtKxYL3bLwu1J6dtdYc6HY/
Rs/5EgpdvgGSEg==
-----END CERTIFICATE-----
---
Server certificate
subject=/C=CN/ST=Beijing/L=Beijing/O=REDHAT/OU=SA/CN=*.apps.cluster0.xxx.opentlc.com
issuer=/C=CN/ST=Beijing/L=Beijing/O=REDHAT/OU=SA/CN=ca.cluster0.xxx.opentlc.com
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2476 bytes and written 487 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: 09B8EB72BE97CFE647C34B7DD31625223A0A4339962426D2973AC2F0B399660A
Session-ID-ctx:
Master-Key: 4F955E66FCA6D60BD7EDF08C2B51458FF6F76F3449EBD1FB34ED3A6EEA6EB91A04A4D19CD006920859A57DE2D9D3E6CC
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - 45 77 ed e9 e7 22 48 4a-de e3 8c 63 69 8f 37 c0 Ew..."HJ...ci.7.
0010 - 5f 07 50 b8 ea 7e fa 4c-60 c5 dd e2 52 d5 1e b9 _.P..~.L`...R...
.....
00b0 - 4e fa 93 06 02 fd ea bc-51 35 49 0d 27 8a 97 ad N.......Q5I.'...
00c0 - 69 29 c2 07 01 8f 9d 21-75 77 f3 87 99 79 1b c1 i).....!uw...y..
00d0 - a7 93 f4 40 e1 6c 94 1e-a8 3d d4 ca 12 6d a0 01 ...@.l...=...m..
Start Time: 1629368848
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
HTTP/1.1 408 Request Time-out
Content-length: 110
Cache-Control: no-cache
Connection: close
Content-Type: text/html
<html><body><h1>408 Request Time-out</h1>
Your browser didn't send a complete request in time.
</body></html>
closed
------------------------------------------------------
(2) Install the ingress certificate related root CA certificate on the Client PC
------------------------------------------------------
The issue have been solved, we can see the openssl verification tell us: Verify return code: 0 (ok)
I provide install root CA certificate method sample for RHEL: (I have provide my rootCA certificate for you in slack message)
# cp myrootCA.crt /etc/pki/ca-trust/source/anchors/
# update-ca-trust
# openssl s_client -showcerts -servername console-openshift-console.apps.cluster0.sandbox1532.opentlc.com -connect console-openshift-console.apps.cluster0.sandbox1532.opentlc.com:443
CONNECTED(00000003)
depth=1 C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = ca.cluster0.sandbox1532.opentlc.com
verify return:1
depth=0 C = CN, ST = Beijing, L = Beijing, O = REDHAT, OU = SA, CN = *.apps.cluster0.sandbox1532.opentlc.com
verify return:1
---
Certificate chain
0 s:/C=CN/ST=Beijing/L=Beijing/O=REDHAT/OU=SA/CN=*.apps.cluster0.sandbox1532.opentlc.com
i:/C=CN/ST=Beijing/L=Beijing/O=REDHAT/OU=SA/CN=ca.cluster0.sandbox1532.opentlc.com
-----BEGIN CERTIFICATE-----
MIIF1jCCA76gAwIBAgIJAPZPYSdAolnlMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNV
......
8UWRMj7/NWbotPqkNEhjy2BdDGcImGC8eQDAA2mlHHo1YXI/816sNTsq6BTz3XyH
kiA7AFjWkzefA+gZbxZC51GUqOrQVKo3zj8oN4tLmXtKxYL3bLwu1J6dtdYc6HY/
Rs/5EgpdvgGSEg==
-----END CERTIFICATE-----
---
Server certificate
subject=/C=CN/ST=Beijing/L=Beijing/O=REDHAT/OU=SA/CN=*.apps.cluster0.sandbox1532.opentlc.com
issuer=/C=CN/ST=Beijing/L=Beijing/O=REDHAT/OU=SA/CN=ca.cluster0.sandbox1532.opentlc.com
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2476 bytes and written 487 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: FA67BEEC045A5C18BD140508D772584A930E7C61504F477171AD229EE0D3C1B6
Session-ID-ctx:
Master-Key: AF6BEA67CB0C80FD1AF59C321A8A71A340E976746D78F4A25D4F3E3F403A95344F5C6A9EDE846CCE3F4DCEA60A4B3323
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - ad 0c f5 2f cb d5 32 89-02 f4 20 93 9b 38 fa 8b .../..2... ..8..
...
00d0 - c5 92 80 98 bf b5 fe fb-56 71 95 e7 bd 17 7c f9 ........Vq....|.
Start Time: 1629369220
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
HTTP/1.1 408 Request Time-out
Content-length: 110
Cache-Control: no-cache
Connection: close
Content-Type: text/html
<html><body><h1>408 Request Time-out</h1>
Your browser didn't send a complete request in time.
</body></html>
closed
Fixed on MTV-2.3.0-11, iib:159147 for OCP-4.10 Franco Bladilo: "Verification on 1994179 will require a Custom CA cert to be added to Openshift, this document explains that and also provides some rationale in how this works: https://docs.openshift.com/container-platform/4.9/networking/configuring-a-custom-pki.html It is basically creating a custom CA, signing the cert and supplying that to the Cluster Network Operator via the Proxy config resource. The MTV operator will detect the presence of a Custom Ingress CA by checking the Proxy resource and proceed to create necessary empty Configmap with proper annotations and perform forklift-ui deployment adjustments." Franco, Further to previous comment, in order to ensure MTV responds as expected to the added cert, could you please answer those queries: 1. What is the name of this created empty configmap? 2. By "perform forklift-ui deployment adjustments", do you mean we should see the forklift-ui pod removed and recreated? If you have any other suggestions on how to ensure that, please share. Thanks. Ilanit, 1. The empty configmap name created by operator is "trusted-ca" , it only creates this configmap when it detects a Custom CA in the cluster Proxy resource. The configmap has also the special annotation of : config.openshift.io/inject-trusted-cabundle: 'true' 2. Yes, the deployment is altered to include this configmap by operator, so it will be recreated More rationale and expectations: Once the trusted-ca configmap is included into the UI pod, it will be mounted in /etc/pki/ca-trust/extracted/pem directory as tls-ca-bundle.pem. The UI image entrypoint script will ensure this certificate is added to the NODE_EXTRA_CA_CERTS bundle file that UI uses, this is by default /opt/app-root/src/ca.crt. This way UI will be now be able to validate any certs on routes signed by the Custom CA. One way to walk certificates added into the NODE_EXTRA_CA_CERTS bundle is to run openssl inside the UI container : openssl crl2pkcs7 -nocrl -certfile /opt/app-root/src/ca.crt | openssl pkcs7 -print_certs -text -noout | grep 'Subject:' There will be multiple certs there, including kube API , Service Signing and Custom CA certs (if any) Looks like MTV is adding an annotation instead of a label config.openshift.io/inject-trusted-cabundle: 'true' LA.
The trusted-ca data is not being populated and the forklift-ui fails to load (unabl
Manually setting the above label resolved the issue.
This is what MTV creates:
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
kind: ConfigMap
metadata:
annotations:
config.openshift.io/inject-trusted-cabundle: "true"
creationTimestamp: "2022-02-14T10:26:52Z"
labels:
app: forklift
name: trusted-ca
namespace: openshift-mtv
ownerReferences:
- apiVersion: forklift.konveyor.io/v1beta1
kind: ForkliftController
name: forklift-controller
uid: 44d3bc18-7933-456f-a019-aa23c0c2057b
resourceVersion: "26687515"
uid: a643a085-3256-4c1f-9049-1a44d8d46001
After setting the Label Manaully to this configmap, it is being populated as expected.
Other than the above, and after setting the label,
There are no auth errors in the UI
and the out custom cert used by ingress seems to be trusted:
$ openssl s_client -showcerts -servername console-openshift-console.apps.mig04.cnv-qe.rhcloud.com -connect console-openshift-console.apps.mig04.cnv-qe.rhcloud.com:443
CONNECTED(00000003)
depth=1 C = us, L = Default City, O = Default Company Ltd, CN = mig04.cnv-qe.rhcloud.com
verify return:1
depth=0 C = us, ST = IL, L = city, O = Default Company Ltd, CN = mig04.cnv-qe.rhcloud.com
verify return:1
---
Certificate chain
0 s:C = us, ST = IL, L = city, O = Default Company Ltd, CN = mig04.cnv-qe.rhcloud.com
i:C = us, L = Default City, O = Default Company Ltd, CN = mig04.cnv-qe.rhcloud.com
-----BEGIN CERTIFICATE-----
MIIDtzCCAp+gAwIBAgIUCYxyPXZlDbY4VfvIJ7hGCUbhI9swDQYJKoZIhvcNAQEL
BQAwZTELMAkGA1UEBhMCdXMxFTATBgNVBAcMDERlZmF1bHQgQ2l0eTEcMBoGA1UE
CgwTRGVmYXVsdCBDb21wYW55IEx0ZDEhMB8GA1UEAwwYbWlnMDQuY252LXFlLnJo
Y2xvdWQuY29tMB4XDTIyMDIxNDA4NTczMloXDTIzMDIxNDA4NTczMlowajELMAkG
A1UEBhMCdXMxCzAJBgNVBAgMAklMMQ0wCwYDVQQHDARjaXR5MRwwGgYDVQQKDBNE
ZWZhdWx0IENvbXBhbnkgTHRkMSEwHwYDVQQDDBhtaWcwNC5jbnYtcWUucmhjbG91
ZC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHy1uQoFbCAFZu
kQNAwbBVIXfituqcnAE2xhynL/mmy+zyCMyQBKhOQqL+jCmw4OAFPooNnA1gYULd
wKNkLlOgwRYnZXZNzxrv5zEM6qr/J55wxmgbCM4SeV+tCC1K4HLSxX8IzEuzz7Tr
jAunk0h5GMFY+IHQSLIsxrdGmRwjDldobszZP/X/WE9h/d30B1vksLOiANPp8x3a
dk9LszVJtz15uvDaJRVoHWkzQRqVcGnzkg8SfPneQj0xG2Mve239/7rk5qwsiWwY
oOC7YdCeWQv2FPYwfL4XVyXuZ1yitdnwgRrcmXyFUMkXnvlZGKCvReepO44VGSdE
U1L+QENVAgMBAAGjWjBYMB8GA1UdIwQYMBaAFMaD48qeJvsToSWjPaQdBEKNcwbY
MAkGA1UdEwQCMAAwKgYDVR0RBCMwIYIfKi5hcHBzLm1pZzA0LmNudi1xZS5yaGNs
b3VkLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADcsEpffCb/64TtPBNz+iqWNdd8Uh
92RGQ5tTZlerU2EHctDriqJdd0K6FybDhZaQE3VKKoPs41Lcr+o0VKF/7fPnjB/w
F8+vbRYkGp570TTcFacslwGp3emdSEh0/6DGstULJqnDSl9X3FG5/ScFaJVAUPBh
umUVTXFZYuIGiZ86r0A7/dWpSqbC5OfC/q6cDynczJ8cgp5eFY1Q5AkBs3dij50a
XkDBQFXD+dUkhdVwNWUoCL+tEhqaBipoFnyq2awrvZTMScn3HB6uwSMFGOHe8rIQ
JGvDLgv+I1exyDMLSW5r58pvpnu2GYUQ+otAHx7GU0CYgrBIrPyLQmLd4w==
-----END CERTIFICATE-----
---
Server certificate
subject=C = us, ST = IL, L = city, O = Default Company Ltd, CN = mig04.cnv-qe.rhcloud.com
issuer=C = us, L = Default City, O = Default Company Ltd, CN = mig04.cnv-qe.rhcloud.com
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 1532 bytes and written 436 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_128_GCM_SHA256
Session-ID: 1BE06587D62E0D597788B338D855852AFE684F7EC1D22A5C6F5E82E14D9B5F36
Session-ID-ctx:
Resumption PSK: C4C3B9D542289BF21255552EF0A187070610DE85245943596268BB67C3A15218
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - fe 53 5e e9 5d 20 ff 8e-fb 9e d4 2f b5 62 f2 92 .S^.] ...../.b..
0010 - 82 19 7e 0b 4d 48 ab 62-db e7 09 6f 51 6b ee 1e ..~.MH.b...oQk..
0020 - c8 e7 97 07 2e 0d 04 bf-77 41 4b 0d f5 1d db a1 ........wAK.....
0030 - af d2 d3 ff 41 b8 4a 62-f5 16 b0 d3 39 fe 68 20 ....A.Jb....9.h
0040 - 93 ce d6 9f 99 b0 78 1a-d8 37 8c 64 b4 65 32 30 ......x..7.d.e20
0050 - 7b 63 8c f5 79 0c d5 83-6d 6d e9 33 ef 7a 7e 14 {c..y...mm.3.z~.
0060 - 3a 75 0f 26 8b f1 26 2c-51 ca 36 51 cf 7a ec 46 :u.&..&,Q.6Q.z.F
0070 - 10 0e c7 33 26 a0 15 cf-1c bc f0 b8 fd ff 0b 3c ...3&..........<
0080 - a2 b6 63 c9 0a 21 bc 65-62 d9 3b 54 2f 0c 4b 65 ..c..!.eb.;T/.Ke
0090 - b7 d6 66 3f 14 61 7d 09-f0 7c e9 9f cb c7 c5 be ..f?.a}..|......
00a0 - ea be e0 3a c2 75 cf 5d-c7 97 53 63 21 08 59 ac ...:.u.]..Sc!.Y.
00b0 - eb 88 63 41 ef 9e 9c df-d8 c5 e6 33 48 c1 d2 a4 ..cA.......3H...
00c0 - 3a b0 c7 a8 f6 ba b8 0a-fe 47 67 6c 14 39 eb 19 :........Ggl.9..
00d0 - d8 4b a8 71 87 2a 52 9e-1f 15 b1 42 d3 7e 9c df .K.q.*R....B.~..
00e0 - d5 1f 6a 06 6c dd 5e e8-a6 13 d2 2d 6c 2c 9c 53 ..j.l.^....-l,.S
Start Time: 1644843318
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_128_GCM_SHA256
Session-ID: 3BAB62ECA33D722A5EBF299062A15F6192FB0F85C4DFB62C749C58137001738C
Session-ID-ctx:
Resumption PSK: A0F396064DD98AD957DF5E6D3CBB668974BE15A0575E36892952AB9D176B22F0
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - fe 53 5e e9 5d 20 ff 8e-fb 9e d4 2f b5 62 f2 92 .S^.] ...../.b..
0010 - 32 af e9 39 87 05 d8 e9-88 f1 ae 69 2c 0b d4 e8 2..9.......i,...
0020 - 04 1c 60 45 4e 28 cf 0c-0a ae 3b 03 41 50 5b d5 ..`EN(....;.AP[.
0030 - e7 46 da 19 2e 26 2a 6d-89 6a bc 40 1a bd f5 af .F...&*m.j.@....
0040 - 05 c4 77 1d e7 ea d8 65-90 a9 8f a3 72 e5 07 4f ..w....e....r..O
0050 - 97 69 66 71 62 4a 26 7b-6f e5 e3 eb f0 e9 ef 4f .ifqbJ&{o......O
0060 - 96 1c a1 0f c4 99 08 35-97 c2 5b 5d b2 69 f4 aa .......5..[].i..
0070 - fa 5d 72 07 da 8e cd de-55 5b 47 c5 c5 d5 d5 5c .]r.....U[G....\
0080 - a6 f8 ba 30 e2 8a 9d 05-c4 f6 8b 7f 95 e0 a9 c9 ...0............
0090 - 7d ea 91 01 1c 68 05 7c-ed 3f f7 1b 54 c1 0c 4f }....h.|.?..T..O
00a0 - 7c d4 cd d7 bc 73 93 7d-92 49 d9 0a 30 0c a2 11 |....s.}.I..0...
00b0 - 2c 31 b4 29 8d 4b 76 70-6d 44 8f 4a dc eb 03 3d ,1.).KvpmD.J...=
00c0 - 55 08 ce 0b 92 85 87 0a-10 d7 01 89 0f f4 1a 54 U..............T
00d0 - 03 d8 8e 39 d8 3f ca c0-23 e3 32 dd bd 7d 95 10 ...9.?..#.2..}..
00e0 - 48 65 cf af 94 46 81 44-0e 7e 99 4a 55 55 07 ae He...F.D.~.JUU..
Start Time: 1644843318
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
HTTP/1.1 408 Request Time-out
content-length: 110
cache-control: no-cache
content-type: text/html
connection: close
<html><body><h1>408 Request Time-out</h1>
Your browser didn't send a complete request in time.
</body></html>
closed
sh-4.4$
OCP 4.10.0-fc.2 CNV 4.10.0-617 MTV 2.3.0-32 Verified: 1. setting ingress rootCA after MTV installation 2. setting ingress rootCA before MTV installation Fixed in MTV-2.3.0-32 Index image v4.9: iib:178078 Index image v4.10: iib:178080 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (MTV 2.3.0 images), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2022:1183 |
Description of problem: Migration Tool virtualization (Forklift) cannot login, and report "Authentication failed" issue When we replace OCP Ingress defaultCertificate as customer's certificate Version-Release number of selected component (if applicable): Migration Tool virtualization v2.0 OCP Version 4.7.21 How reproducible: Steps to Reproduce: 1. import customized root and router certificate 2.replace ingerss defaultCertificate oc patch ingresscontroller.operator default --type=merge -p '{"spec":{"defaultCertificate": {"name": "myrouter-crt"}}}' -n openshift-ingress-operator 3.remove and recreate openshift-mtv operator\operants\namespaces Actual results: we can open openshift-mtv first page Click Getting Start buttom, MTV need us to Oauth from OCP login page When we input OCP credential, and then redirect to MTV page, the MTV page tell us ""Authentication failed" Expected results: we expect MTV webui can work with customized ingress certificate Additional info: