In wso2is 5.11.0 user trying to self register cause a "javax.net.ssl.SSLException: hostname in certificate didn't match: != ........." exception. The same configuration with same keystore and trust-store works fine if backported to 5.10.0.
Thanks
Francesco
In WSO2 IS-5.11, the server hostname for internal API calls is by default configured as localhost. This configuration is utilized to build the internal absolute URL of a service endpoint, which will be consumed at places that will generate internal API calls.
If you are configuring the hostname for evaluations (when there is no load balancer or proxy) you can follow this.
Add 'localhost' as SAN for the certificate (-ext SAN=dns:localhost)
Here is a sample keystore generation:
keytool -genkey -alias newcert -keyalg RSA -keysize 2048 -keystore newkeystore.jks -dname "CN=wso2is.local, OU=Is,O=Wso2,L=SL,S=WS,C=LK" -storepass mypassword -keypass mypassword -ext SAN=dns:localhost
Also, if you are using single-node deployment(there is no load balancer or proxy) instead of adding SAN, defining internal_hostname value as the same as hostname value will resolve this issue
[server]
hostname = "is.dev.wso2.com"
internal_hostname = "is.dev.wso2.com"
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 have created an SSL cert via DigiCert and imported to ACM. (I require the same SSL to be applied to both ALB and the Application, and since there's no way to import ACM certs, I had to follow this way)
I have successfully imported the SSL and can see it in the console. However, I cannot apply it to ALB 443 Listener.
I provided the Cert ARN to the CloudFormation template and it fails stating certificate don't exist.
I have tried to manually update the 443 Listener, but the cert is not listed
Since both failed, I have tried to import the cert in the ALB Listener console, but got the below error message. (However, certificate gets imported and I can see it in the console)
Updating listener failed. The imported certificate's configuration is
not compatible and will not appear in the list of available
certificates for your listeners. Select or upload a different
certificate and try again.
There is a Limitation of updating HTTPS Listener for Your Application Load Balancer.
ACM supports RSA certificates with a 4096 key length and EC certificates.
However, you cannot install these certificates on your load balancer through integration with ACM.
The solution is to try uploading these certificates to IAM in order to use them with your load balancer.
This should help.
Did you check whether the SSL cert key algorithm is supported by the Application Load Balancer? These are the supported Algorithms:
Source:https://aws.amazon.com/premiumsupport/knowledge-center/elb-ssl-tls-certificate-https/
You can check the Key sizes using these commands:
$ openssl rsa -in secret.key -text -noout | grep "Private-Key"
Private-Key: (2048 bit)
$ openssl x509 -in certificate.crt -text -noout | grep "Public-Key"
RSA Public-Key: (2048 bit)
As mentioned by #aress-support, you can use IAM to import the certificate.
https://aws.amazon.com/premiumsupport/knowledge-center/import-ssl-certificate-to-iam/
We are using cloudfront to serve images with a custom domain.
http://images.example.com/fubar.png
We want to be able to access them with SSL, eg https://images.example.com/fubar.png
We have a wildcard SSL certificate (issued from Godaddy) for *.example.com and I used the AWS Certificate Manager to upload the certificate, private key, and keychain. The upload appears to have been successful as *.example.com appears to be issued (according to the Certificate Manager).
I'm then following the instructions to Update the CloudFront Distribution and I added images.example.com, selected the option for Custom SSL Certificate and made sure Distribution State was enabled. When I click the Yes, Edit button I get the following error:
com.amazonaws.services.cloudfront.model.InvalidViewerCertificateException: The specified SSL certificate doesn't exist, isn't in us-east-1 region, isn't valid, or doesn't include a valid certificate chain. (Service: AmazonCloudFront; Status Code: 400; Error Code: InvalidViewerCertificate; Request ID: a62cf849-d495-11e7-94d9-673e2e2905b1)
I've used this SSL certificate elsewhere with success. If it helps, I originally created this cert using a Windows machine to make the request and then downloaded the cert from Godaddy. I don't have access to this download anymore, but I do have access to a PFX file on a Windows Server. I took this PFX file (which has the private key) (named SSLWildcard.pfx) and used OpenSSL to get the certificate and private key. I used the following commands:
openssl pkcs12 -in SSLWildcard.pfx -nocerts -out SSLWildcard.key
openssl rsa -in SSLWildcard.key -out SSLWildcard-decrypted.key
openssl pkcs12 -in SSLWildcard.pfx -clcerts -nokeys -out SSLWildcard.crt
I used the contents of the CRT and KEY files (I used the decrypted key file) and GoDaddy's public certificate chain file gd_bundle-g2-g1.crt. I've tried using various certs (and combinations) from GoDaddy's public repository but I'm kind of just guessing. Any ideas as to what I'm doing wrong?
The error message has one clue: When using a cert for cloudfront, it must be in us-east-1.
You don't mention what region you uploaded the cert to, but if you're deploying to cloudfront make sure it's in us-east-1.
If the certificate is in us-east-1, there is one other clue:
Error Code: InvalidViewerCertificate
If you are using an S3 bucket configured for public web hosting, you cannot communicate between cloudfront and s3 over https - it must be http. See here for details.
I have hosted my site on Shopify and own a domain. Now I need to host my backend web application on AWS. However the communication between shopify and AWS needs to happen in HTTPS. I have created AWS environment using elasticbeanstalk app with ELB (Elastic load balancer). I have configured ELB to use HTTPS and provided the certificate, generated using openssl like below.
openssl req -x509 -newkey rsa:2048 -sha256 -nodes -keyout elasticbeanstalk.key -out elasticbeanstalk.crt -subj "/CN=elasticbeanstalk.com" -days 3650
I have also successfully followed all steps mentioned here https://medium.com/#arcdigital/enabling-ssl-via-aws-certificate-manager-on-elastic-beanstalk-b953571ef4f8
However I still get privacy error with "NET::ERR_CERT_AUTHORITY_INVALID" in the browser when I hit the ELB url using https
I think I'm lacking something basic here. My confusion is that, which domain should I use to when creating the self signed certificate (My own domain or elasticbeanstalk.com or something else )? Is there anything else I'm missing?
The issue is that you are using a self-signed certificate.
Browsers ship with a list of trusted root certificate authorities. When HTTPS is used, the SSL certificate has a chain of authority which must end with a root certificate authority recognised by the browser.
The easiest solution in your scenario would be to use an Amazon Certificate with your ELB. These are available for free from the Amazon Certificate Manager which can be found in the AWS console.
Request a certificate (In the same AWS region as your ELB), follow the instructions to validate it and it will appear in the drop down options when choosing a certificate for the ELB.
in wso2 esb i want to add a https proxy service and but when in define proxy service in specity source url use https://... in test url get error :
Invalid WSDL URI (Unable to establish a connection)
and in next step in definr endpoint use of an endpoint https:// ... this error apear :
Unable to validate SSL Certificate of https://....
i try to certificate a crt file and in my https proxy service in wso2\repository\resources\security\client-truststore.jks with keytool
%JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA
and enable https transport sender and recsiever in axis2.xml but my problem do not solve.
I guess, you are trying to connect to a HTTPS endpoint using proxy service. Here you want to import the endpoint server's certificate chain in the the "client-truststore.jks" flie and restart the server. However; by default HTTPS transport sender and receiver are enabled. You may not need to enable them.
But few things to remember..
In transport sender, if you do NOT want to verify the host name of the end point server with its certificate, Please configure "HostnameVerifier" property to "AllowAll". If not, if your end point server's IP and certificate CN are not matched, It would create some errors.
If end point server's certificate is a self signed on, you can just import the server's certificate. If it is a CA singed on, You need to import all the CA certificate chain.
(However most common CA certificates can be found in the "client-truststore.jks" file)
If you want to change the trust store or key store files, you can do it using transport sender configurations. By default trust store file is "client-truststore.jks" Also, if you did any changes to axis2.xml file or key stores, Please restart the server.
Also If you want to expose your proxy service using SSL, you need to enable the "https" in the proxy service. And then your client needs to user ESB server's certificate to call the proxy service.