We are using WSO2 integrator 6.4. To be able to connect to 3rd party HTTPS servers, we need to add server's certificate to client-truststore.jks. A lot of servers now use certificates from https://letsencrypt.org with 3 months TTL.
That means we must renew certificates every three months for every 3rd part server in our enviroment otherwise we get "Error in Sender" error.
Is there a way to disable certificate checking in WSO2 EI at all?
Or maybe it is possible to make some automatic scenario to renew certificates in client-truststore.jks?
Or can we check certificates in client-truststore.jks inside wso2 ei itself and send warnings before expiration?
A little basic in TLS trust.
When do you have explicit trust, trusting individual certificates (often done for self-signed certificates). Indeed this approach creates significant management overhead, mainly when onboarding, offboarding new service hosts or with short-lived certificates.
For TLS (SSL) an implicit trust is used. Your application trusts a list of (long lasting) the issuers - Certificate authorities (CA). Event the list of the CA certificates change over time, so some manual management may be necessary anyway.
Is there a way to disable certificate checking in WSO2 EI at all?
Yes, there is (in axis2.xml), but that lowers the security and the traffic would be vulnerable to a man-in-the-middle attack.
We solved this issue by adding only root CA certificates of letsencrypt to client-truststore.jks.
Yes, this is the correct approach. If you have closed environment (not able to access internet), you may need to add all the certificate chain (root and iternmediate signing certificates)
We solved this issue by adding only root CA certificates of letsencrypt to client-truststore.jks. That was enough for wso2ei to trust all servers with certificates of Letsencrypt.
Related
Using WSO2 APIM 2.6.0 seems the primary keystore certificate is used for multiple purposes
service (nio-https) SSL - that can be easily changed
signing a JWT token to the API Gateway backend service
thrift SSL endpoint for the Traffic Manager (port 9711)
The issue I have is that in a distributed setup a separate gateway should reach the TM endpoint and the hostname needs to be trusted. So - in theory I can create a self-signed certificate with a new hostname, however a new keypair/certificate will break existing backend validating the JWT token.
In theory I may just create a different self-signed certificate with the same public key, it may be more complex to manage in long run (I don't want to promote this practice).
Question: Is there a way to configure either the JWT signing certificate or the thrift SSL certificate separately? Or disable hostname validation for the throttling service (port 9711)?
(I'm not sure we want to allow disabling the hostname validation globally)
Since you have a distributed setup, this can be achieved easily.
You need to change the certificate in the gateways so that they use that keystore for the TM connection.
Keep the KM keystore as it is so that JWT is signed using the same old keystore.
We have a Webservice Application running on Tomcat.
This is SSL secured. We need to share our public key to every client trying to access our web services. Is it possible to disable the trust certificate verification ?
By default, all TLS clients should verify the servers to which they are connecting. Any other default behavior would be dangerous.
The client is the party performing the verification in a one-way TLS handshake (that is, when there is no client-authentication being performed where the client also presents a certificate to the server).
There are only two ways to avoid distributing your server's certificate to all possible clients:
Get your server's certificate signed by a trusted Certificate Authority (CA)
Modify all possible clients to ignore any problems with your certificate (such as not trusting it)
These days, with free domain certificates available from e.g. Let's Encrypt, it's silly not to use a certificate signed by a legitimate CA.
Is there a way to validate domain control without using the email process? As I need to be able to add additional domains to the certificate for new clients...
The problem I'm facing is I can't add to the existing AWS certificate and have to create a new one with all the domains. When I do that everyone for every domain get's emailed and asked to confirm at:
administrator#domain.com
hostmaster#domain.com
admin#domain.com
postmaster#domain.com
webmaster#domain.com
So I have had to register a seperate certificate and upload it to ACM instead which is not ideal. Mainly as it's limited to 99 domains and was hoping to automate the whole process.
Is this possible with AWS?
Thank you.
Q: Are any other methods for validating a domain or approving a certificate supported?
Not at this time.
https://aws.amazon.com/certificate-manager/faqs/#provisioning
Having so many domains on one certificate isn't really a good practice, for other reasons, as well.
You're making your certificate physically longer and longer, wasting some amount of bandwidth, because the cert is sent to every connecting client, on every new connection.
Renewals will also be messy, if any of the domains on the cert are no longer pointing to your site, because auto-renewal requires that the issued cert be reachable on the Internet for each hostname.
ACM tries to automatically renew your Amazon-issued SSL/TLS certificates before they expire so that no action is required from you. To renew your certificate automatically, the following must be true:
ACM must be able to establish an HTTPS connection with each domain in the certificate.
For each connection, the certificate that is returned must match the one that ACM is renewing.
http://docs.aws.amazon.com/acm/latest/userguide/configure-domain-for-automatic-validation.html
One cleaner solution (the one I am using) is to provision each domain's cert individually, and attach each one to its own CloudFront distribution, pointing that to your origin server (which I assume in this context to be an ELB) and whitelisting all headers for forwarding to the origin, which bypasses caching and causes CloudFront to function as a simple but distributed reverse proxy. Setting "compress objects automatically" in CloudFront may also save some bandwidth charges, and even with caching disabled, CloudFront should improve the responsiveness of your sites by keeping traffic on the AWS network for more of the path between origin and viewer.
I am currently writing a desktop app which will need to communicate with PHP scripts on my remote server via https(with a self-signed certificate). The server-client communication code is still in the planning stages, however because I haven't yet figured out how to verify (on the client) that I am actually communicating with MY server. I'm presuming that there is some way to verify the servers identity using the certificate. I am intending to use WinHTTP for the https communication, providing it has all of the functionality that I need.
To greatly oversimplify things: clients verify the server's certificate by using a hardcoded list of trusted certificate authorities. The certificate authority list is an internal list of certificates that's baked into the client, and the client verifies that the certificate presented by the server is signed by one of the certificate authorities that the client trusts.
So, no matter what you end up doing, your client will have to keep some kind of a list of certificates that it trusts. This is a fundamental aspect of the TLS trust model. You could simply include your self-signed certificate with the client, and the client verifies that that your server presented the same certificate.
But the right answer is to run your own certificate authority. It involves some additional advance prepwork, but the end result will work much better. Instead of the several dozen, or so, standard certicicate authorities that are either included in your operating system, or your browser, your client will have exactly one trusted certificate authority in its trust list: your own certificate authority, and your client will verify that your server's certificate is signed by your certificate authority.
I need to secure communication between my application and my Web Service.
I own both the application and the Web Service, and I was wondering if it is possible to use HTTPS to do so.
I don't need a certificate to prove to myself who I really am (!), so I don't want to buy an SSL certificate from a Certificate Authority. I just need to make sure no one can intercept the data I pass as WebMethod parameters; Can I create a free certificate and use that to secure communication?
One other thing: I don't want to be forced to get a dedicated, public IP address for my Web Service since it is hosted on a shared Web server.
Definitely it's doable, but hinges on a few conditions.
Create your own self signed certificate. The lack of a certificate authority won't matter in your case because your app is your own consumer.
The host must allow you to configure your IIS site with an SSL cert. Hopefully the tools they provide are good enough.
The shared IP that your web site has currently cannot have more than one certificate bound to it. You're now at the mercy of your host to not move your site to a different IP. It may or may not have an SSL cert on another site at that time. Basically - the first one wins. An IP cannot have more than one cert-secured website.
There are many articles out there showing how to create and install a self signed certificate in IIS. What you need to remember is that this certificate will not be valid as it is not delivered by a certificate authority. Once you set a certificate on the server side you need to indicate to the client to accept the invalid certificate by using the ServerCertificateValidationCallback property:
ServicePointManager.ServerCertificateValidationCallback =
(sender, certificate, chain, sslPolicyErrors) => true;
You can't use a SSL certificate (self signed or otherwise) without a dedicated IP address. Unless your shared hosting provider provides a shared SSL certificate on your IP, you will need to purchase a dedicated IP.
If you want to go through the trouble of doing it, you can use a self-signed certificate and have a tertiary server (or use the IIS server that is self-signing) to be your own certificate authority. This would allow you to generate your own certificate for free, then since you have control over the servers, you could just add your CA server as a trusted and intermediary root certificate authority.
Creating Certificate Authorities and self-signed SSL certificates