What happened:
When importing from an HTTPS service that has an invalid or malformed certificate, it is not possible to override the security check with an "insecureSkipVerify" type option. This can occur when you have a self signed certificate, but the subject name is incorrect, or the SAN names are incorrect. Defining/configuring a certConfigMap does not resolve this type of error.
What you expected to happen:
It is not always possible to fix the certificate on the endpoint, so it should be up to the end user to allow the importer to bypass the TLS check. The user should be able to override the check with an "insecureSkipVerify" option on the source, allowing the creation of the volume to complete.
How to reproduce it (as minimally and precisely as possible):
Create a datavolume definition that uses an HTTPS datasource. The certificate on the source should be self signed, but have invalid information for the SAN. You will be unable to import the datasource even if you define a certConfigMap.
Additional context:
This was discussed in the slack thread https://kubernetes.slack.com/archives/C8ED7RKFE/p1780500582897189 . I will be submitting a PR to resolve this issue shortly.
Environment:
- CDI version (use
kubectl get deployments cdi-deployment -o yaml): ALL
- Kubernetes version (use
kubectl version): N/A
What happened:
When importing from an HTTPS service that has an invalid or malformed certificate, it is not possible to override the security check with an "insecureSkipVerify" type option. This can occur when you have a self signed certificate, but the subject name is incorrect, or the SAN names are incorrect. Defining/configuring a
certConfigMapdoes not resolve this type of error.What you expected to happen:
It is not always possible to fix the certificate on the endpoint, so it should be up to the end user to allow the importer to bypass the TLS check. The user should be able to override the check with an "insecureSkipVerify" option on the source, allowing the creation of the volume to complete.
How to reproduce it (as minimally and precisely as possible):
Create a datavolume definition that uses an HTTPS datasource. The certificate on the source should be self signed, but have invalid information for the SAN. You will be unable to import the datasource even if you define a certConfigMap.
Additional context:
This was discussed in the slack thread https://kubernetes.slack.com/archives/C8ED7RKFE/p1780500582897189 . I will be submitting a PR to resolve this issue shortly.
Environment:
kubectl get deployments cdi-deployment -o yaml): ALLkubectl version): N/A