I am installing the Mailbox and Client Access Roles into a Server 2012 server, and this server already has IIS installed on it and hosting a Web Application in the Default Web Site. That already existing website has had it's http port bound to 85 instead of 80 though (which I would have thought made this easier).

I cannot find a way that I can specify which Website for it to install the Client Access. Letting it install by itself merges with the existing web application, and the SSL settings cause it to break.

Any insight would be helpful.

CAS will be installed in Default Website. It's not recommended to install CAS server on a web server.

Why are you installing Exchange on a server that is already hosting another application?  This could definitely lead to resource contention between your website and Exchange.  Exchange is going to want all the resources it can get.  I would recommend standing up a new machine and dedicate it to Exchange.  From my understanding (although I can't find documentation yet that says otherwise) the only OWA/ECP can exist outside of the Default Website. 

I do agree with both of you have exchange should always have it's own dedicated server, but that choice is out of my hands unfortunately. I have a good paper trail with the powers that be where I clearly outline what a bad idea this is (is you think having another IIS site is bad... they also have MSSQL running on it *facepalm*)

Fun bit of info so far though - I setup a VM with a fresh version of 2012, added and added IIS. I then did several things to help me do some testing.

• I renamed the "Default Website" to "Original Default Website" and changed it's ID to 3 and bound to http port 85.
• Added another website called "Another Site" with the ID of 1 and bound to http port 81
• Added another website called "Default Website" with the ID of 2 and bound it to http port 82

Ran the exchange installer and here are the oddities that happened

• Another Site has a https 443 binding added to it, but other notable changes
  
• Default Website had the PowerShell application added to it
• Installer crashed saying cannot find the PowerShell app in Default website

Well I'll post the solution that seems to be working fine (initial testing seems to be working without issues)

1. Rename that "Default Website" to something else, and change it's ID to something other than #1 under the Advanced Settings in IIS. I suggest #3 so that the Exchange Back End gets created as #2 and keeps it organized.
   We do this because some parts of the installer seem to select the WebPage to install to by name, some by ID.
   
2. Create a new WebSite called "Default Website" and ensure it's ID is 1. Give it a http 80 and https 443 binding.
3. Stop the IIS server, and edit the file c:\windows\system32\inetsrv\config\applicationHost.config with notepad. In the <site> section, make sure your "Default Web Site" is the first on in the list of sites. Other parts of the installer just pick the first site in the configuration and ignore the name and ID.
4. Start IIS back up, and install Exchange.

Well I'll post the solution that seems to be working fine (initial testing seems to be working without issues)

1. Rename that "Default Website" to something else, and change it's ID to something other than #1 under the Advanced Settings in IIS. I suggest #3 so that the Exchange Back End gets created as #2 and keeps it organized.
   We do this because some parts of the installer seem to select the WebPage to install to by name, some by ID.
   
2. Create a new WebSite called "Default Website" and ensure it's ID is 1. Give it a http 80 and https 443 binding.
3. Stop the IIS server, and edit the file c:\windows\system32\inetsrv\config\applicationHost.config with notepad. In the <site> section, make sure your "Default Web Site" is the first on in the list of sites. Other parts of the installer just pick the first site in the configuration and ignore the name and ID.
4. Start IIS back up, and install Exchange.

• Proposed as answer by Allen_WangJFMicrosoft contingent staff, Moderator 4 hours 36 minutes ago
• Marked as answer by Allen_WangJFMicrosoft contingent staff, Moderator 4 hours 36 minutes ago

It's a workaround that can work in someone scenario and don't work in someone else's scenario. It's not recommended but when we don't have any choice you know we need to fit within the resource whatsoever the case but my friend if in future you guys need help with your Exchange and you go to Microsoft then Microsoft probably won't be able to support as you guys are not running recommended or i should say standard configurations. Thanks.