Does anyone know of a project / product that has standardized how to access/download x509/SSL certificates over HTTP? I have seen RFC 4387 but haven't found anyone who implements it. Basically, I am trying to setup a key server for an internal application.
So short of implementing my own, does anyone have any suggestions?
That is the only "standard" for an HTTP-accessible certificate repository, but I've never seen it implemented. Most CAs that provide an HTTP repository do not use a standard, machine-accessible interface. For example, Verisign provides a certificate repository for certificates it issues to US government employees, and makes it accessible through a form-based web application.
For a machine interface, "everyone" uses LDAP. More importantly, while LDAP-enabled clients are common, I've never seen a client application that supported an HTTP interface. What do you plan to do with an HTTP repository?
Related
I'm looking at how to set up a secure connection between a WCF service, and a non-.NET client running on RHEL, so I expect Windows authentication is not feasible. This is just for an internal network, so I'm hoping to avoid the management headaches of X.509 (e.g. needing to closely monitor certificate expiry dates), but I'm not clear on whether it's technically possible to do so.
Is it possible to configure a WCF service with e.g. BasicHttpBinding or WsHttpBinding so that it has encryption (either transport or message layer, I'm not picky), but without using Windows authentication support or X.509 certificates?
Every scenario I've read for secured WCF services seems to use one of those two technologies. The only ones which don't require any X.509 certificates all use Windows authentication. I'm not sure if this is a fundamental consequence of the underlying technologies or if it's just a property of the "common scenarios" that Microsoft has chosen to document. At the moment I'm assuming that if Windows authentication isn't available, then X.509 is the only way to deploy public/private key pairs for the non-Windows-specific message encryption algorithms to use. Is this understanding correct?
well ... it's just that "common" property ...
x.509 is the common way to do this in your scenario, since the most things needed for this are already there ...
but you are not limited to either windows auth or x.509 ...
take a look here: http://www.codeproject.com/Articles/165844/WCF-Client-Server-Application-with-Custom-Authenti
the article describes how you can introduce your own authentication and encryption schema ...
i've already done that (simple AES encryption, one key among all clients), but i don't have the code at hand ... it wasn't that hard, but if you really run into trouble here, i'll have a look if i still have that stuff somewhere...
The ColdFusion documentation is weak on how and when to use it. What does it do? How does one use it?
Update: it seems to be broken, as outlined in Washing Client Certs in ColdFusion with SOAP – Part 2.
problems with CFHTTP handling SSLv3 sessions
Client certificates are a bit of a pain because of the overhead involved in using it.
As Jura says, you'll need a target server that uses client certificates as a mechanism for authentication. This server side piece does not need to be CF-based. The web server (IIS, for example) would be set up to require this. This is part of the SSL/TLS protocol, not specific to any language at the application level.
You would use this if the server you are requesting a resource from requires client certificates. The administrator of that server would need to give you the client certificate and private key ahead of time. As mentioned by user349433, this is commonly a PKCS12 (.p12 or .pfx) file.
The server will validate that the client certificate is "trusted" and if it is, it will allow the TLS/SSL handshake to proceed, and CF will be able to write the HTTP request on top of it.
The use case today is to prevent man-in-the-middle attacks, but because of the overhead involved with certificate distribution, revokation, etc. it's not terribly common.
If you want to know more about it, check out TLS 1.1 specification:
https://www.rfc-editor.org/rfc/rfc4346
https://www.rfc-editor.org/rfc/rfc4346#section-7.4.6
You are using client certificate in case if the target server uses that mechanism for authentication. You'll need to obtain specific client certificate from the service provider in order to be able to connect to the service. It's been used for some internet banking applications back in days I believe. Not sure what is the use case today for it, may be distributed corporate networks where you need to connect to corporate server over internet in a highly secure manner?
so I'm currently trying to make an OpenID provider. I've tried using two Java based OpenID server packages- Atlassian's Crowd, and WSO2 Identity Server. Now, in my implementation, security is a must, which means using SSL and having HTTPS based OpenIDs. Now, for both WSO2 and Crowd a large number of sites simply do not work with the OpenIDs provided. Of 20 sites tested, 8 failed with Crowd, and 10 failed with WSO2. This high failure rate is not really acceptable. Virtually every site which has a problem claims that they cannot find an OpenID endpoint.
When I used the OpenIDs without SSL (so HTTP based OpenIDs) suddenly the sites were far more compliant, with only two of them failing. I am using a certificate from AusCERT, so the problem should not be due to self-signed certificates.
At first I thought that this was just a matter of there being a large number of RPs which simply did not accept HTTPS based OpenIDs. I tried logging into the same sites I was failing on with an HTTPS based OpenID from Verisign though, and it worked. Looking closer at both WSO2 and Crowd I discovered that neither completely conformed to OpenID 2.0 specification- in particular, neither of them provide a link in the head to an XRDS document for yadis discovery. Considering that my problem is that sites cannot discover an OpenID endpoint at the URL I give, it seems relevant except that when I do not use SSL the HTML based discovery is sufficient.
Does anyone have any insight as to where my problem really lies? The missing XRDS document seems like it should be relevant, but it could just be a red herring. Baring that, if anyone knows a good alternative to Crowd or WSO2 which is well documented, works well to spec, and is (relatively) easy to configure, it would be nice to know!
One thing to look at is that some Providers' SSL certificates are not signed by root authorities that are considered authoritative by some RPs. Make sure you get your certificate from one that all RPs trust.
If .NET is an option for your provider, check out the free and open source DotNetOpenAuth library, which you can host yourself and is used by some major OPs such as MySpace and netidme.com and others. It's implementation of OpenID 2.0 is complete, it supports the U.S. government ICAM OpenID 2.0 Profile, and has been used for many interoperability, security and compliance tests, and it works with both OpenID 1.1 and 2.0 RPs so you'd be very likely to have good interoperability with many/all RPs. It has a bunch of additional security features that you can just switch on (like requiring HTTPS as you said is a requirement).
(Full disclosure: I wrote DotNetOpenAuth.)
I have a WCF service and client which is going to be deployed to several companies (hundreds). Some companies will run the software in their network and some will run it over the Internet (WCF server at on office, WCF client at another).
We want to encrypt the communication between the WCF server and client. We don't have any need to authenticate the cient / subscriber using WCF security, because we have our own username/password log-in which the clients will use to log on the server.
We can't rely on Windows auth because some of the users will run it over the Internet, and the WCF server may not be on the same domain as the WCF client.
If we use "real" certificates*, companies running the software would have to purchase certificates from a CA and install it, and then configure our software to use it, but this is too complicated for most of them.
We could auto-create certificates during installation of the WCF server, but then we would have to automatically install it into a certificate store and somehow automatically grant IIS permissions to read the certificate. This is more complicated than we would like.
In short, we want a simple solution where the encryption is just based upon a shared secret, in our case the username / password the user is logging on with. I do understand that this won't give the best available encryption, but we're willing to trade some of the security to make the software easier to deploy.
Is this possible?
*With "real" certificates, I mean certificates purchased from a certificate authority, and not one I've created myself / self-signed.
If you want to encrypt the messages on the transport (which is a really good idea!), there has to be some shared knowledge between the sender (the client) and the server. This can be hardcoded, but that's really not a good idea at all - if that "common shared" knowledge is ever compromised, an attacker could decipher and read all your messages.
Also, since it's definitely not recommended practice, there's no support of any kind in WCF to simplify using a shared secret. You're on your own - you have to roll your own 100% of the way.
The only viable way to have a common shared secret exchanged in a safe way is to use a certificate. No way around this, sorry. The certificate doesn't even have to be used for user authentication or anything - but it establishes a shared secret between the caller and the service and thus allows the caller to encrypt the messages in such a way only the intended recipient can actually decrypt and use them.
So I really don't see any way you can get around having certificates on your servers - doesn't need to be on every client, but on every server where your service runs.
Marc
PS: if you really want to investigate the "hardcoded shared secret" approach, you'll need to think about this:
how do you store a shared secret safely on each and every single one of your clients?
how do you use information from that stored shared secret to encrypt your messages?
Typically, the approach would be two-fold:
exchange some form of a private/public key pair; the server generates a key pair and keeps the private key to itself and shares the public key with the client (e.g. over a WCF message, for instance)
using that private/public key pair, exchange a common shared secret, e.g. an "encryption key" that will symmetrically encrypt your messages (and since it's symmetrical, the server can use the same key to decrypt the messages)
setup infrastructure on your client (e.g. a WCF extension called a behavior) to inspect the message before it goes out and encrypt it with your shared secret
All in all, it's really not trivial - anything simpler than that is not worth being called "security" at all.
If you look at all that work you will have to do - wouldn't it be easier to just use the WCF built-in certificate mechanisms??
Decent security worth its salt is hard - so why not leverage what's available instead of doing all the work yourself, or worse: come up with a half-baked solution that's so easy to crack you could just as easily send everything in cleartext..... don't under estimate the complexity and amount of code needed to handle even the most basic security scenarios - WCF does this all for you - for free and in a reliable and safe manner - use it! You won't regret it!
Well, with WCF you could use Password credential at message level and SSL at transport level, which I think would be enough in your case.
See here.
For message security, your client provides some credentials and server provides some credentials. For this setup and with your scenario could you not use the client username and password with a Custom Username Validator, and a server certificate to provide the server credentials. This Application Scenario provides a fair chucnk of the configuration setup you would need to achieve this, except the aspNet membership sections, which you would have to replace with your custom validation config.
You would still need valid certificates on your servers (no certificates required on the clients), but I can't see any way around this.
Take a look at the following sample:
http://www.codeproject.com/KB/WCF/wcfcertificates.aspx
It uses certificates but without a certificate store - so no setup is necessary.
Hmm.. maybe something simple could be used. Move the encryption from software to hardware. VPN from each client network to your own and then you can do whatever you like for WCF transport. The line is not clear text and the problem is solved.
Of course this is easier said than done, but most network vendors provide a pretty easy VPN config and it maybe easier than trying to develop an installer for SSL certs and configure the client.
I hope it helps!
I have a client/server WCF application that needs some sort of user authentication against a database. The application (both client and server together) is being developed to be sold to dozens of customers, for use on their intranets. We're not too worried about encrypting most of the data moving across the wire, except of course during authentication.
Thinking about WCF security, I keep coming back to the idea that we should be making use of x509 certificates. However, our customers will definitely not want to know about any of the details of having to apply for, purchase and install these certificates.
I'd like to know first of all what the preferred method is of implementing username/password authentication in this scenario. If it will require using certificates, must the customer apply for their own certs from a trusted CA, or can we as the software provider generate certificates for the customer to use?
Really I'm looking for a best practice, with the least friction to our customers.
Thanks!
Edit: I'm using NetTcpBinding, and my server is running as a Windows Service.
So username/passwords does not require client certificates as I'm sure you're aware, it simply requires an HTTPS certificate on the server hosting the WCF service - once you have that you can happily use the standard username/password auth bits (WCF will not allow message based authentication without HTTPS).
If you wanted to head down the client certificate root you get the advantage of non-repudiation - you can be sure that the machine sending is who it says it is (unless someone has stolen the certificate, which is less likely than a username and password combination going walk about). You as the software provider could act as your own certificate authority and generate your own client certs (there are a few ways to do this depending on your infrastructure) but then you need to configure the clients to trust your root CA.
If the server and client are running in a domain environment you could use transport security with Windows authentication (you're using tcp binding, so interoperability is out the window anyway!) The added bonus to this is the authentication is transparent and you don't need any certificates anywhere. If you want verfication of the server identity then message security with Windows authentication will do the trick.
I've got project in production which is similar to your scenario. I have a Windows Service hosting endpoints via netTCPBinding and I used x509 certs... although in my case, the intent was to encrypt both the transport and message layers, as I was crossing over untrusted security boundaries. I was less concerned with providing authentication/authorization other than requiring the certificate be present.
Similar to your intranet scenarios (I'm assuming), I had authority over the server and client machines at installation time... or at least could dictate some of the terms of installation.
Rather than purchase the x509 certs and burden the client with that expense, I opted to roll our own. We set up one of our Win2003 servers to be a CA, issuing our own Certification Authority cert. We then generated an x509 cert for the server, as well as individual x509 certs for the clients.
The client and server certs were installed on both clients and server (as appropriate) into the personal user store at the computer level. We also installed our CA cert directly into the Trusted Root Certification Authorities section, thus making our client and server certs trusted.
Because I was less concerned with authentication/authorization, I don't know what to recommend as a best practice for dealing with binding certs to individual users and going more granular than machine-level (my solution was windows service to windows service communication -- completely unattended). I would think you'd need a cert for each user, installing it into their personal user store in the certificates MMC. The runtime implementation will be guided by how you configure WCF to do the cert lookup, so it should be fairly easy.
Throughout the process, I relied heavily on what I'd learned from this great CodeProject article: Securing WCF Services with Certificates. It walks you through generating/installing the certs. The sample WCF applicatoin is IIS-hosted, but I was able to pretty easily translate the config sections from web.config to app.config.
In my case, I exposed the Web interface for requesting certificates in Win2003 to the web itself, so the client could request certificates directly in the future. We have approval control, so it works well. I haven't had a need to generate new certs yet, so I can't say how much friction that would entail.
If your going to be crossing firewall boundaries then certificates are going to be your best solution. I don't know much about the specifics about applications for certificates or your application. Unfortunately, as far as i know, i think you will have to help them apply for certificates or they will have to do it their self unless they want to undertake in the process of installing their own certificate server. If the app will be internal then windows authentication will work and is VERY easy but if you think your going to have clients that user your application across firewall boundaries then you might as well invest the time in using certificates because certificates will work everywhere. Now there is something called federated security where you delegate the permission of authentication to another entity. I think this is used if say you have to domains and you want to delegate permission say of someone on another domain that is not on your domain to their domain but its pretty complex and my understanding of its very limited but by the sound of your requirements certificates is the way to go.
Security is not supposed to be easy :)