I am running JBoss with SSL, the certificate is generated with openssl:
<Connector protocol="HTTP/1.1" SSLEnabled="true"
port="8443" address="${jboss.bind.address}"
scheme="https" secure="true" clientAuth="false"
keystoreFile="${jboss.server.home.dir}/conf/chap8.keystore"
keystorePass="password" sslProtocol = "TLS" />
My client is an AIR application which interacts with the Java EE Server through GraniteDS. On the Flex/AIR side, I updated the channel to a SecureAMFChannel on services-config.xml:
<channel-definition id="myApp-graniteamf" class="mx.messaging.channels.SecureAMFChannel">
<endpoint uri="https://localhost:8443/myApp/graniteamf/amf"
class="flex.messaging.endpoints.SecureAMFEndpoint" />
</channel-definition>
Now, when I connect from my client, AIR asks me if I want to go ahead with the connection (view certificate, etc.).
I'm new to the whole SSL/HTTPS concept, but I've read some docs. What I'm trying to figure out now, is how to make my App know that a server is safe (localhost in this case). From what I got so far, the client application should "trust the server as a CA", or just trust the certificates from a certain server.
Can you give me some clues as to where to start to implement this on my AIR client side application?
If I understand correctly, you are using a self signed certificate. Going on that assumption you can't force a user to accept the certificate through your AIR app, that would be a security hole. To get a call from your AIR app to be trusted the user would need to import your certificate (or the untrusted CA you signed your certificate with) into their own keystore.
The way you do this is different for each OS, but an example of how to do it in Windows is to browse your server in IE, Get the cert warning, view the cert details and then export the cert to file (X509 iirc). Then you can right click the cert file and chose to install the certificate.
All subsequent calls to that secured server should then be trusted.
Related
I'm trying to implement transport level security for WCF services.
My application architecture is as follows:
WCF service is hosted as windows service in domainA.
Client is a WinForms application in DomainB.
Since it's a cross domain scenario, I have to use certificates for authenticating client and service so they can establish a secure connection.
My understanding is I need 3 certificates to achieve this:
Service certificate - authenticates the service to the client.
Should be installed in Local Machine --> Trusted Root Certificates store on a service machine.
Certificate authority - a certificate that can be used to issue user specific certificates. Where should this one be installed? Service or client machine?
User certificate.
Should be installed in Current User --> Trusted Root Certificate on a client machine.
I couldn't find any examples on the web that use certifcate authentication over tcp protocol.
I could only find https examples with services hosted in IIS.
Any reference to a tcp scenario is greatly appreciated.
Are my assumptions correct?
Where should I install the Certificate Authority certificate (item 2)?
Are there other, easier approaches besides using certificates to accomplish transport level security over tcp in a cross domain environments?
Thank you in advance.
I received the following question. Any help would be greatly appreciated!
What I need to be able to do is configure SSL to validate the target endpoint’s SSL certificate against the base trusted roots (typically provided by the OS and/or Java). There is no documentation that tells me how to turn on SSL certificate validation or if I add a TrustStore if it will guarantee that the SSL cert is validated against that. The only tutorial I see that is related is for SSL Client Auth, which we are not using.
Validation of backend SSL server certificates is explained on this page. Note that the page documents how to achieve mutual authentication, where the gateway would both validate the target server's SSL certificate (which you want), and send a certificate to the target as identification (which you do not want).
To validate the target's certificate, you create a truststore and upload all certificates in the trust chain for your target server. The documentation mentions only uploading the target server's certificate (which works if your target server is using a self-signed cert), but you'll want to upload the entire trust chain of certificates if you are using a non-self-signed cert. Creating and uploading to the truststore is shown in step 6 on the page above.
Then, you'll want the target endpoint configuration to look like this:
<TargetEndpoint name="default>
<HTTPTargetConnection>
<SSLInfo>
<Enabled>true</Enabled>
<ClientAuthEnabled>false</ClientAuthEnabled>
<TrustStore>myTruststore</TrustStore>
<IgnoreValidationErrors>false</IgnoreValidationErrors>
</SSLInfo>
<URL>https://myservice.com</URL>
</HTTPTargetConnection>
</TargetEndpoint>
ClientAuthEnabled=false indicates that the gateway will not send a certificate to the target.
IgnoreValidationErrors=false will cause the connection to abort if the certificate returned by the target cannot be validated using the certificates in the truststore. IgnoreValidationErrors=false is the default, so you could leave it out and it would work as desired. However, if you are having problems communicating with your target server, it may be useful during testing to set the ignore flag to true to allow communication even if the certificate fails verification (just to isolate your problem). Just be sure to set it to false in production.
The xsd schema for the SSLInfo element can be found here.
I am trying to use SSL and certificates with a web service (IIS 7, Windows 2008, .NET framework 3.5 SP1). I followed the basic instructions (http://learn.iis.net/page.aspx/144/how-to-set-up-ssl-on-iis-7/) and was able to get the site running soon. However, I can only connect to it from a client if the client has the web server's certificate in its Trusted Root Certification Authorities/Certificates store. If I don't add the certificate on the client site, I get the error "Could not establish trust relationship for the SSL/TLS secure channel with authority" on trying to connect to the service from client.
That's the correct behavior if you're just using self-signed test certificates. In a public/production environment, your server's certificate would be issued by a common CA like GoDaddy or VeriSign, which you have to pay to obtain.
Most (client) machines already have a large list of updated CA in their trusted root such as GoDaddy, and so a server certificate signed by them for your site will validate as a valid certificate on most* machines (without you needing to provide your cert as a trusted root).
*Most, meaning that there are browsers & operating systems which may be missing (or need updates) on common certificate authorities in their trusted root store.
Where did you get this certificate? If it's not a child of one of the certificates in the root authority already I sure hope you didn't pay money for it. If you're generating them yourself this isn't surprising because nobody trusts your CA server.
In our flex/air application we are calling a web service over https. The web service is java based and has, at the moment, an untrusted certificate.
When doing a POST to the service with some json, the payload on the server side is pretty garbled. A popup does occur asking whether you want to continue and even when I do and add the untrusted certificate into my keychain (on the mac), the data sent through always comes through mangled.
I installed charles http proxy to see the actual traffic and it seems at times I'm getting a SSLHandshakeException back... I'm guessing this is causing the garbled data as ssl isn't being setup properly.
So, to the question - can air/flex handle untrusted certificates? Is there a workaround that you can do? For example in java with commons httpclient you can work around it at the socket level.
Thanks,
Kieran
I don't know but it might help if you use the secure attribute in your server-side crossdomain.xml like this:
<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-from domain="mydomain.com" secure="false" />
</cross-domain-policy>
In my project I need to connect to an intra-net web service but we need SSL connection between the two machines.
Because this is an intra-net site the certificate of the web service might be a self-signed certificate.
The web service and the web page that loads my Flex application resides on the same web server (tomcat) so when I load the web page of the application with HTTPS I been asked to confirm the certificate, I confirm it but this confirmation does not apply on the Flex application (on Internet Explorer and Firefox).
I tried Google's Chrome and it actually asked me twice for confirmation, one for the web page and one for the connection to the web service so it worked great.
Is there a way to tell Flash player to accept also self-signed certificates of is it entirely concern the browser and Adobe guys can't do nothing about it?
In other words, is there a way to connect to a self-signed certificates HTTPS web services from Adobe Flex???
Thanks.
When I put on my security hat the answer would be I hope not. I don't want browser plugins to bypass my browser security settings. I'd consider that a vulnerability.
There might be a way for standalone Air applications, but in browser Flash should honor browser settings.
In your company, you could create your own root CA, add its certificate to all machines that will access the intranet, and then have the CA issue your web service a certificate. The certificate will no longer be self-signed. The two main issues are: (1) managing the private key of your CA, (2) distributing the CA's root certificate to client PCs.
You need to download the cert and install it on both IE and Firefox.
To install a cert on IE:
http://www.markwilson.co.uk/blog/2008/11/trusting-a-self-signed-certificate-in-windows.htm
To install a cert on FF:
Go to Tools->Options and click on the Encryption tab. Click "View Certificates", then "Import".
In my experience, the cert has to be either verified or installed in the browser in order to get Flash to work properly. The cert also needs to have a valid hostname, but you can just edit your client's hostfile if you need to do this for testing.
Well, the flash player should just use the browser to make the connection and be done with it. We have a similar setup here. We use self-made certs, and communicate with the an AMF channel over HTTPS. My guess is though that our setup is different in that we load the flash application itself over an HTTPS channel, so it's talking from HTTPS to the same HTTPS server. Maybe you could try that? This is the setup for our Tomcat server:
Tomcat Server/Client Self-Signed SSL Certificate