I have configured HTTP end point using Amazon API gateway.
Further I have added custom domain along with SSL certificate.
However on invoking api , I am getting Execution failed due to configuration error: General SSLEngine problem.
Now what is confusing that same SSL certificate works well for other Amazon API configured apis.
The API back end is Play Web Service and is being served through Nginx.
From Cloud watch logs , I do not find much relevant information.
It is possible that the issuer of your server certificate is not trusted by API Gateway.
Just For info.
Following analysis could be one of the reason for above issue.
The mentioned problem was being faced on following configuration.
Operating System :- UBUNTU 16.04 X64
NGINX :- 1.10.X
The issue was resolved on downgrading to following configuration.
Operating system to UBUNTU 14.04 x64
NGINX to 1.4.6.
Though I am not sure , it appears to me that the problem with Nginx 1.10.x.
Execution failed due to configuration error: General SSLEngine problem is a common error in the API Gateway private integration (VPC Link) and HTTP Integration.
General SSLEngine problem can be observed in following scenarios, when Integration returns :
A certificate signed by issuers API gateway do not trust
An expired certificate
A self-signed certificate
Certificate signing chain/chain of trust is missing the root certificate or one or more intermediate certificates
Any other unrecognizable certificate-related exceptions
Read More here - https://cloudnamaste.com/general-sslengine-problem/
I faced the same issue and then I contacted my SSL Support/Company and they added the intermediate certificate into the actual SSL certificate file using JavaKeyStore - which solved the issued
Related
I am using AWS load balancer to listen to dev.example.com and api.dev.example.com. I have added amazon managed certificates in the listener for both the subdomains. I can connect to dev.example.com successfully, but for api.dev.example.com I am getting an SSL error. I am using AWS default security policy(ELBSecurityPolicy-2016-08). I did sslscan for api.dev subdomain and got the following error
TLS Fallback SCSV:
Connection failed - unable to determine TLS Fallback SCSV support
TLS renegotiation:
Session renegotiation not supported
TLS Compression:
OpenSSL version does not support compression
Rebuild with zlib1g-dev package for zlib support
Heartbleed:
Supported Server Cipher(s):
Unable to parse certificate
Unable to parse certificate
Unable to parse certificate
Unable to parse certificate
Certificate information cannot be retrieved.
Why is sslscan failing for api.dev subdomain while it is successful for dev subdomain? How can I resolve this?
Second level subdomains have to be listed in the SSL certificate. If you have a *.example.com wildcard certificate the wildcard is only valid for one level. You would also need to add wildcards for other levels, like: *.dev.example.com.
This is not a limitation of AWS, it is a limitation of SSL certificates.
I am posting this here to help others facing this problem as I could not find any useful information on the web.
If you have mapped your ACM certificate to an end-point (EC2, ELB, EKS service.. whatever) You will need to enable
CertificateTransparencyLoggingPreference
Else you will get:
NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED
Error in chrome. To do this via the aws-cli, the command is:
aws acm update-certificate-options --certificate-arn <ARN of ACM certificate> --options CertificateTransparencyLoggingPreference=ENABLED
I have provided the full response from AWS support as the answer, as this contains even more information.
This is Vivek from AWS Containers team. I will assist you on this
case.
From the case description, I understand that you requested an ACM
certificate and created ELB(service load balancer) behind which you
are running nginx pods in EKS cluster example-EKS-CLUSTER-dev.
When accessing the site https://test-aws.example.co/ from browser you
are getting error as below:
Error: NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED
You would like to use a third party CA such as lets encrypt to issue
free SSL certificate for your domains. You do not want to move the
domain to Route53.
You wish to know how to to do this and achieve https.
Please let me know if my understanding is correct.
Regarding the error ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, this error
is thrown by Chrome browser when it can not find CT(certificate
transparency) logs.
For Google Chrome to trust the certificate, all issued or imported
certificates must have the SCT information embedded in them.
By default ACM logs all new and renewed certificates. However, it
provides option to opt out from AWS API or CLI.
You may find more about this on link [1].
I checked the load balancer mapped to the domain “test-aws.example.co”.
It is mapped to ELB
abce6962e05794f36a23435db3f1837d-1755308045.eu-west-2.elb.amazonaws.com
which uses ACM certificate
arn:aws:acm:eu-west-2:150737547637:certificate/f932b11d-af17-4023-be41-045c6fcc5e86
I checked this certificate and found that the option
“CertificateTransparencyLoggingPreference” is disabled.
You may enable transparency on the certificate to fix the issue by
running following command:
aws acm update-certificate-options --certificate-arn --options
CertificateTransparencyLoggingPreference=ENABLED
Once the certificate is updated with
CertificateTransparencyLoggingPreference as enabled, the issue will
resolve i.e. you should not longer receive the error
NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED when accessing the site
over https.
Regarding your other query, i.e. how to use a third party certificate
such as LetsEncrypt with ELB for https, you may obtain the desired
certificate(get it issued from desired CA) and import it in ACM or
IAM. Once the third party certificate is imported in ACM/IAM, it can
be associated with the https listener of ELB similar to how you
associate certificate issued by ACM(by using annotation
service.beta.kubernetes.io/aws-load-balancer-ssl-cert in service
definition yaml with value as the ARN of imported certificate).
Please find the steps to import certificate in ACM on link [2]. The
steps to import a certificate in IAM can be found on [3].
I am using WSO2 API manager 3.2.0 and I am faced with a probelm when I configured load balancing with Nginx and multi instance, as following :
schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted.
Could you please guide me how to solve it? I know that is SSL_Certificate issue and for example we can invoke api wit -inactive or deisable ssl verification in post man, but I want to solve it. I have studied in document that there is wso2carbon.jks that is default keystore , so how to solve problem with defualt key store?
The mentioned error is happening since you are using Self-Signed certificates in your environment. The cURL doesn't trust the Self-Signed certificates when trying to invoke the APIs. Therefore, if you want to overcome this behavior, you have to generate a CA-signed certificate and configure the environment.
You can refer to the following docs to generate and configure CA-signed certificate with WSO2 API Manager.
Furthermore, if this is your local setup, you can move forward with the -k flag in the cURL command to bypass and make an insecure connection with the API Manager.
How can we set HTTP proxy for GCP C++ SDK?
Setting env variables using the "http_proxy" does not seem to have an effect.
Setting the SSL_CERT_FILE env variable also does not affect the SSL certificate path. CURL always seems to be using the default certificate directory.
Also, is there a way to disable SSL certificate verification in the GCP C++ SDK?
This seems like a duplicate of this question on GitHub:
https://github.com/googleapis/google-cloud-cpp/issues/5584
I have answered there.
I'm trying to use Cloudfront for the first time.
Here is my infrastructure:
Created an alias (CNAME in OVH) from my domain name to the cloudfront domaine name
I have a cloudfront distribution deployed with the following configuration (see below)
I'm using an EC2 custom origin, in where I have installed Nginx (reverse-proxy) accepting traffic on port 443(https) and redirecting traffic of port 80(http) to 443(https)
I'm using a valid SSL certificate (until Sept 2018) that I created using letsencrypt and uploaded it to ACM (cert.pem -> Body / privkey.pem -> Private key / fullchain.pem -> chain`)
In Nginx I'm referencing the fullchain.pem and the privkey.pem
Here is my configuration
While troubleshooting I have done the following:
Used an SSL checker (https://www.sslchecker.com/sslchecker) which tells me that the certificate and the chain were find but not the root. BTW other online SSL checkers say that everything is ok. Don't know if the issue is coming from here. Amazon CM finds that the private, certificate and the chain are OK.
Used Openssl
openssl s_client –connect domainname:443 –servername domainname
openssl s_client –connect domainname:443
The first command is ok but the second is giving me SSL HANDSHAKE ERROR.
But Cloudfront is not configured to allow non SNI clients. So I think it is ok
- Checked my domaine with https://www.ssllabs.com/ssltest/ for ciphers & protocols. Everything seem to be ok. I can give more details if necessary
I'm still getting:
"CloudFront wasn't able to connect to the origin."
Any help please?
thank you