 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Server Forum / IIS / IIS Security / July 2008creating multiple client certificates
Hi All, We have a requirement to connect a few pcs and windows mobile devices across the internet to an internal webserver. We would like to have SSL connections and the additional security of client certificates. We have a CA server (which is also an Exchange server to create certificates for Outlook Web/Mobile access). And have set up the webserver, enabled SSL with a server cert from the CA, but now want to enable client certificates for the internal webserver, so we can distribute to all of the clients. Can I just make one client cert that I put on all of the clients (if so how exactly?), or do I have to connect each client to the CA's Certsrv to get the client cert? (I don't want to do the client cert/user account mapping). Any help/advice appreciated Many thanks, Al On Jul 10, 6:09 am, Alastair <Alast...@discussions.microsoft.com> wrote: > Hi All, > [quoted text clipped - 16 lines] > > Al I do not understand what you are trying to accomplish with the client certificate. Based on your description, the certificate does not add security but does add hassle for you, so I am not certain what you are trying to accomplish. If you do not map or otherwise validate the client certificate, then anyone can send anything and simply bypass this added "security". Furthermore, to be effective security, a Client Certificate must be directly presented between the client and the server. Internal server may go through some NAT layer, which would prevent this scheme from being secure since to the web server, the traffic is originating from the NAT, not end-client. What you'd end up with is SSL certificate termination at the NAT instead of internal webserver, which is not the security improvement you are looking for. Finally, how to put certificates on a given device depends on the device. From a security perspective, this process cannot be initiated by the client, so you have to physically install a certificate onto the client device -- there is no way for the client to remotely connect and install the certificate because that is insecure. In short, I am really wondering about your requirement because as described, it is not accomplishing its goal of providing additional security, so I really do not know what is required -- the certificates, increased security, or something else. //David http://w3-4u.blogspot.com http://blogs.msdn.com/David.Wang // Hi David, thanks for your reply. Perhaps I’m getting the wrong idea of certificates. I’ll try to explain what we want to do, our setup is as follows: firewall connected to the internet which allows a port (not 443) through to the port configured as ssl on the iis server. We want to only allow the 10 or so PC’s and WM6 devices through that we have configured to connect. This is where we thought that having a client certificate would provide additional security (by stopping any other pc connecting), i.e. we would manually install the client cert (only applicable to the iis server) only on the authorised pc’s/wm6 devices. To gain access to the web application, the user has to enter a username/password, so the client cert does not have to authenticate the user onto the active directory. If we use no client cert at all, are we making the IIS server more vulnerable to any security problems by opening the firewall port through to that server? Thanks again for your help, it is much appreciated! Alastair. On Jul 14, 12:55 am, Alastair <Alast...@discussions.microsoft.com> wrote: > Hi David, > thanks for your reply. Perhaps I’m getting the wrong idea of certificates. [quoted text clipped - 15 lines] > > Alastair. To me, your usage of Client Certificate does not improve security. By opening the firewall port, you are allowing SSL traffic to IIS. Client Certificate does not affect any "security problems" due to such opening. Client Certificate is something negotiated on that SSL handshake, but unless something authorizes based on the certificate, providing it is useless and does not improve security. IIS Certificate Mapping only performs an authentication mapping -- no authorization -- so you will need to provide custom code to perform your custom authorization scheme to lock down access. Personally, the username/password should be sufficient lockdown to those users. The certificate help lockdown further to only those devices, assuming you've taken care to not allow those certificates to be copied and transferred between devices. //David http://w3-4u.blogspot.com http://blogs.msdn.com/David.Wang // Hi David, Thank you for taking the time to reply. Simplistically I thought you produce a certificate on the iis server, this can then (or from CA) produce a client cert that can then be exported and copied/installed on the clients. When the client (with cert installed) tries to connect via https the server checks if the client has the cert, if so it connects, if not the connection is refused. Thus stopping the users from getting onto the application from just 'any' pc - just the ones with a client certificate pre-installed by us. Am I able to generate and copy just one client certificate for this purpose? Thanks again, Alastair. On Jul 14, 6:21 am, Alastair <Alast...@discussions.microsoft.com> wrote: > Hi David, Thank you for taking the time to reply. > [quoted text clipped - 10 lines] > Thanks again, > Alastair. A certificate can be created anywhere by anyone. The question is whether the users of the certificate trust the authenticity of the certificate. The issue is that there is no server-side feature which "checks if the client has the cert" to authorize/deny the user's connection attempt, so your usage scenario will require custom code. //David http://w3-4u.blogspot.com http://blogs.msdn.com/David.Wang // Hi, "no" - it doesn't work that way. When a client connects over HTTPS, and the webserver is configured to allow/require client certificates, then the server sends a list of all the CAs that it trusts to the client. The user is then prompted to select a certificate that has the User Authentication OID embedded in it, and that is issued by one of the CAs that the web server trusts. Caveat: that's how the major browsers all work (what list actually gets presented to the client is entirely a UI thing, so a browser could present any arbitrary list of certificates installed on the machine). The browser then sends this cert back to the server. It is up to the server to then accept/reject it. So, not having a cert doesn't really prevent a connection. To really be useful as a security measure requires issuing individual client certificates (if you use AD, then you can just auto-enrol users so there is no work on their part - and the certificate <-> user mapping is handled automatically for you). If you issue individual client certs, then you know who is connecting (which is the whole point - client authentication), and you can also revoke a certificate if it gets compromised. The way you are suggesting is a risk - if one PC gets compromised/lost/stolen/whatever, what are you going to do? You need to revoke the cert, and reissue every single cert you had before. > Thus stopping the users from > getting onto the application from just 'any' pc - just the ones with a > client > certificate pre-installed by us. Client certs are user based - not machine based. You're basically trying to use a technology for one purpose for some different purpose. And unfortunately, when it comes to security, this is generally insecure (i.e. there are ways to circumvent or subvert the process), and it generally makes your environment more complex and less secure. Cheers Ken > Hi David, Thank you for taking the time to reply. > [quoted text clipped - 14 lines] > Thanks again, > Alastair. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.