Don't bundle the SSL cert with the installer

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   Hello,

I'm requesting a change to the Mac client so you don't need to embed the SSL certificate in the installer. SSL for the client-server communications is a must in our environment, and I'm concerned about what is going to happen when the SSL cert expires. Why not just validate the cert as it is provided by the console when the endpoint checks in, like the Windows client does?

Thank you,
Dan

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
dwoodruff Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 24 Nov 2010 Location: Rochester, NY Status: Offline Points: 71	Post Options Post Reply Quote dwoodruff Report Post Thanks(0) Quote Reply Topic: Don't bundle the SSL cert with the installer Posted: 07 Jan 2011 at 2:55pm
	Hello, I'm requesting a change to the Mac client so you don't need to embed the SSL certificate in the installer. SSL for the client-server communications is a must in our environment, and I'm concerned about what is going to happen when the SSL cert expires. Why not just validate the cert as it is provided by the console when the endpoint checks in, like the Windows client does? Thank you, Dan

RITJeremy Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 21 Dec 2010 Location: Rochester, NY Status: Offline Points: 34	Post Options Post Reply Quote RITJeremy Report Post Thanks(0) Quote Reply Posted: 18 Jan 2011 at 3:25pm
	We would like to see the client use the certificate chain provided by the keychain mechanism built into Mac OS X. All of the certificate chains we will use are already there — either by being included with the OS, or that we have installed on our managed clients. It may make sense to be able to specify which certificate chain is acceptable for IDF usage via policy, since so many certs are trusted by the system by default.

dwoodruff Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 24 Nov 2010 Location: Rochester, NY Status: Offline Points: 71	Post Options Post Reply Quote dwoodruff Report Post Thanks(0) Quote Reply Posted: 28 Jan 2011 at 12:31pm
	A stop-gap alternative could be an addition to the new "Client Updates" component of the console. There could be an additional deployment option for the Mac cert, allowing a cert to be replaced before it expired. The better alternative that I did not know how to articulate is what RITJeremy outline - using the built in certificate chain.

djc6 Members Profile Send Private Message Find Members Posts Add to Buddy List Newbie Joined: 21 Dec 2010 Location: Cleveland, OH Status: Offline Points: 19	Post Options Post Reply Quote djc6 Report Post Thanks(0) Quote Reply Posted: 02 Feb 2011 at 7:10pm
	A concern of mine as well. I'm not sure the "Client Updates" mechanism is best - you'd have to remember to push it out while the cert was still valid. If you waited too long you'd have no way of communicating with the clients.

RITJeremy Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 21 Dec 2010 Location: Rochester, NY Status: Offline Points: 34	Post Options Post Reply Quote RITJeremy Report Post Thanks(0) Quote Reply Posted: 25 Feb 2011 at 11:40am
	We are using the root certificate authority certificate of the server’s leaf certificate, and as far as I know, it is working. Following the instructions from the following article: http://support.identityfinder.com/entries/75901 ... we made a single change. We export the root certificate, not the parent certificate immediately above the server‘s own certificate. In our case, we are exporting the root CA and not an intermediate CA. Depending on the CA chain you are using, the ability to set up IDF Mac Edition with the root CA or an intermediate CA should lower concerns about certificate expiration. If a leaf certificate were required, that would be a very reasonable and valid concern. I was not able to export the certificate from Safari and convert it with OpenSSL in a manner that worked with IDF Mac Edition, fwiw.

Product Management Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 24 Nov 2010 Status: Offline Points: 172	Post Options Post Reply Quote Product Management Report Post Thanks(0) Quote Reply Posted: 12 May 2011 at 12:05pm
	All - thank you for the feedback. There are number of questions, suggestions, and concerns above - so we'd like to propose a solution and gather feedback. There are a few scenarios here - at the very least, certificate expiration and certificate replacement. Our thoughts are to allow you to specify (via settings) the URL of a server that allows http connections. You could use your console server if it allows http, but if it only allows https connections, you would need to use another web server. This is obviously to work around the situation of expired certificates which would prevent the endpoint service (eps) from connecting to the server to check for the new cert. Each time the eps starts, it would check the url to see if the specified cert was newer than its own. We haven't yet worked out the exact details - such as if a text file with a cert date would be lower overhead than checking the cert itself - but we can figure out if the overall idea is acceptable. If the cert at the url is newer, the eps would replace the local cert and continue on its way. Additionally, any time an error is encountered due to an expired certificate, the url would be checked/new cert downloaded. For cert replacement, you could just put up the new cert on the web server and then reboot all of the machines and they would check and download the new cert. We would still require that a valid cert be included in the installation package and allow this solution for its replacement/update. All feedback, thoughts and comments are encouraged.

mot1psu Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 24 Nov 2010 Location: Penn State Status: Offline Points: 26	Post Options Post Reply Quote mot1psu Report Post Thanks(0) Quote Reply Posted: 31 May 2011 at 2:21pm
	This would work for us in the interim, but that would require a second web server be stood up since we only allow connections via https to the console. This however would be preferable to have the distributed IT staff push out a new pkg or not have console connectivity when we update the cert

RITJeremy Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 21 Dec 2010 Location: Rochester, NY Status: Offline Points: 34	Post Options Post Reply Quote RITJeremy Report Post Thanks(0) Quote Reply Posted: 14 Jun 2011 at 1:41pm
	We haven't had to deal with this requirement on the Windows client and it would be helpful to understand why it is needed on the Mac client. I reiterate my suggestion to use the existing Mac OS X Keychain mechanism to configure trust. In my environment, we are pushing out a CA certificate that is already installed on every Mac by default. (We don't push out the leaf node certificate, we go up the chain of trust to the root, and the roots expire far less frequently than any leaf certificates do.) I can certainly see wanting to limit which CA can be used with IDF and its endpoint service. Perhaps you can have something in the client configuration which can be pushed from the console server which will allow us to specify which CA(s) are valid for IDF use. If this were an array, we could start adding in a future CA as our needs change, and then remove the old one once the transition has been accomplished. It is a bit difficult to understand what your goal is in requiring installation of a certificate in the client file system. Perhaps you can explain that further. We definitely want move away from including any certificates in the installation package (as a file that must be installed).

dwoodruff Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 24 Nov 2010 Location: Rochester, NY Status: Offline Points: 71	Post Options Post Reply Quote dwoodruff Report Post Thanks(0) Quote Reply Posted: 30 Jun 2011 at 5:00pm
	I've been pondering over Jeremy's root certificate method on and off for a few hours, and I plan to give it a try tomorrow. Question though - won't specifying a root cert in the client remove some degree of the authentication that SSL provides? Technically, couldn't a man in the middle attack between the endpoint and console intercept the connection using any valid SSL cert signed by the same root CA? If the endpoint is only checking the validity of the cert at the root level, anything below it would be ignored by the client, right? For example: Say I have a Comodo cert for myidfconsole.coolschool.edu applied to my console. In my endpoint, I'm including Comodo's root cert. Joe Badguy somehow gets in the middle of the connection between endpoint and console, and presents the cert for myevilsite.com to the endpoint, also signed by Comodo. Won't the endpoint trust it because we're only validating at the root cert level? Please prove me wrong if I'm thinking about this incorrectly :) And I understand that the feasibility of a man in the middle attack depends on a variety of network architecture factors and may not be easy or profitable for an attacker to pull off for Identity Finder, so the risk is low, but it would be a risk nonetheless. Dan

RITJeremy Members Profile Send Private Message Find Members Posts Add to Buddy List Groupie Joined: 21 Dec 2010 Location: Rochester, NY Status: Offline Points: 34	Post Options Post Reply Quote RITJeremy Report Post Thanks(0) Quote Reply Posted: 01 Apr 2013 at 4:31pm
	If you have the potential to have certificates signed by the same root CA that could masquerade as your IDF server, that would certainly create an issue. I'd say you probably have bigger issues, though, in root CA management if that's the case. By definition, you have to trust a CA to a certain extent. This could be partially fixed by transmitting a whitelist of accepted certificates (fingerprints) that that agent will allow. However, that would have to be securely handled in such a way that the masquerading server couldn't impersonate that and send a bogus whitelist. Note that OS X currently has 181 trusted root CAs in the System Roots keychain. If you have a commercial certificate chain for your IDF server, the chances are probably pretty good that your CA provider is listed with at least one root. If you use an internal CA, you're likely to be setting up IDF on clients that are managed to one extent or another. In that case, you have to install the IDF agent, so you could also use standard, accepted OS X practices -- which, as of this writing, now include iOS-like configuration profiles -- to install certificates and set up trust.