As part of updating the SSL/TLS certificate of the web server deployed in the Kubernetes(which the current one will expire soon), I updated the Kubernetes secret (kubernetes.io/tls) with the new crt and key.
After that, the application works fine in the browser.
But, the API calls to the server, (From some python applications running in some pods) are hitting some SSLError.
The same will work if I restore the old certificate for the server.
The error is:
requests.exceptions.SSLError: HTTPSConnectionPool(host='hostname',
port=443): Max retries exceeded with url: URL(Caused by
SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED]
certificate verify failed: unable to get local issuer certificate
(_ssl.c:1131)')))
I tried to resolve this by creating the crt and key in different ways from the pfx file.
But the issue remains.
I did some search on - if anything to update in the Kubernetes cluster as part of the certificate change and I couldn't find a solution.
Any help will be greatly appreciated.
The issue was, the certificate I installed was without the intermediate certificate. The browsers may "fill in the gap" by searching for the missing certificate. Re-install the certificate with the complete chain resolved the issue
Related
Having problems installing PayPalCommerce in OpenCart,
After installing and trying to connect to PayPal I get this error!
"(60) SSL peer certificate or SSH remote key was not OK"
As anybody else come across problem as the server certs are just fine?
As Stated Server Certificats are fine, was thinking of changing the Curl SSL Veerify to False but that would defeat the whole purpose. And as the latest Security 1.2 (whatever abrevation).
Update your certificate authority bundle so that your HTTPS connection to the PayPal API endpoint can verify the connection is trusted.
One can be downloaded here, among other places.
If your attempted connection is using a specific certificate file rather than a CA bundle, delete the old certificate and either obtain the endpoint's current one to use instead or use CA verification of it
I am new in Kubernetes and stuck on the issue. I was trying to renew letsencrypt SSL certificate. But when I try to get certificate by running following command
kubectl get certificate
System throwing this exception
Error from server: conversion webhook for cert-manager.io/v1alpha2, Kind=Certificate failed: Post https://cert-manager-webhook.default.svc:443/convert?timeout=30s: x509: certificate signed by unknown authority (possibly because of "x509: ECDSA verification failure" while trying to verify candidate authority certificate "cert-manager-webhook-ca")
I have checked the pods also
The "cert-manager-webhook" is in running state. When I check logs of this pod, I get the following response
I have also tried to apply cluster-issuer after deleting it but face same issue
kubectl apply -f cluster-issuer.yaml
I also have done R&D about this but could not find any suitable solution. Whats the issue here? Can someone please help me regarding this? Thanks.
The problem was with "cert-manager-cainjector" pod status which was "CrashLoopBackOff" due to FailedMount as secret was not found for mounting. I have created that secret and after that it start working fine.
In my case, I was attempting to install an older version of cert-manager onto my cluster, and Simply pulling the latest version of cert-manger (1.10.1 at time of writing) and installing that worked.
When attempting to install an older version of cert-manager I saw the following error from the cainjector pod.
error registering secret controller: no matches for kind "MutatingWebhookConfiguration" in version "admissionregistration.k8s.io/v1beta1"
I assume that the API admissionregistration.k8s.io/v1beta1 has been removed between K8s versions 1.21 and 1.24, and that's why I encountered an issue.
if you are using webhook, check if you have injected the ca, if not you could do it using:
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
...
annotations:
cert-manager.io/inject-ca-from: "<namespace>/<certificate_name>"
Ubuntu server 16.04 PHP7.4 Apache2 running wordpress Geotrust SHA256 certificate
I have started getting the following error
cURL error 60: SSL certificate problem: unable to get local issuer certificate
I have read through and tried most solutions on the many questions on here, but to no avail
The latest 2 i have tried is adding to php.ini the following 2 lines and restarted Apache and rebooted after each one to see if it solves the issue. But it does not
After downloading a fresh copy of cacert.pem The first one i tried was
curl.cainfo = "/path/to/cacert.pem"
Then i tried
openssl.cafile = "/path/to/cacert.pem"
But i still get the same error
Any assistance greatly appreciated.
Many thanks
This is likely to be a server problem ("unable to get local issuer certificate" often is):
Even when using a CA bundle to verify a server cert, you might still experience problems if your CA store does not contain the certificates for the intermediates if the server doesn't provide them.
The TLS protocol mandates that the intermediate certificates are sent in the handshake, but as browsers have ways to survive or work around such omissions, missing intermediates in TLS handshakes still happen that browser-users won't notice.
Browsers work around this problem in two ways: they cache intermediate certificates from previous transfers and some implement the TLS "AIA" extension that lets the client explicitly download such cerfificates on demand.
To figure out for sure if this is your problem, use a TLS test service like perhaps this one: https://www.ssllabs.com/ssltest/
I don't know much about this topic, but have a site (shared hosting) and want ssl for it. Got a certificate from letsencrypt (for both www and plain mydomain.com), they verified it successfully, so I put the cert and private key into the ssl config part of cpanel. Cpanel marked the inputs valid but then gave me the following error
The certificate could not be installed on the domain “mydomain.com”.
error Certificate verification failed!
Certificate verification failed:
unable to load certificate
140495454865312:error:0906D064:PEM routines:PEM_read_bio:bad base64 decode:pem_lib.c:812:
I have no idea what this means. Any help would be appreciated.
Got it working by making sure every line was exactly 64 characters long
My app connects to Worklight server through HTTPS through self-signed certificate. The app can be launched successfully.
However, when there is direct update which started downloading file from Worklight server, it is failed and I can see that there are error message regarding certification path not found.
May I know if the SSLHandshakeException and direct update error are correlated?
Thanks!
(Environment: Worklight 5.0.6.1, WAS ND 8.5, Testing Device: HTC One)
10-31 21:24:50.897: W/System.err(28746): Catch exception while startHandshake: javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
10-31 21:24:50.897: W/System.err(28746): return an invalid session with invalid cipher suite of SSL_NULL_WITH_NULL_NULL
10-31 21:24:50.927: E/WLDroidGap(28746): Failed downloading application update file.
Yes, the use of direct update and the SSL handshake errors are related. Android doesn't allow you to work with self-signed certificates (unless you somehow bypass SSL). Because you can't install a self-signed cert into Android's truststore, the Android client can't establish trust for the server's self signed certificate.
You probably have the following flag specified in your Android manifest file:
android:debuggable="true"
This flag disables SSL validation when going thru the hybrid channels and probably the reason why you don't see the SSL errors earlier. Direct update is handled at a different level, where this flag does not apply, and therefore SSL validation does occur.
You should use self-signed CA certificates instead for dev/test purposes. See the following answer on how to generate a self-signed CA:
https://stackoverflow.com/a/19841469/2494287
Direct update will not work with a self-signed certificate. It is intended to be used in production, therefore it will only accept a valid CA cert.