In a SAN cert, the common name isn't that important because when the client checks the cert, it will find all names and as long as the site name it is connecting to is one of the names in your second picture, it will work.
With that said, is your testing client a member of the test domain you're using? I needs to be. It's possible that the trusted root certificate of the CA giving out the certs in your test domain is not in the trusted root store of the client. An easy way to make sure it gets in there automatically is to apply a GPO to the client turning on AutoEnrollment. http://technet.microsoft.com/en-us/library/cc947849(v=ws.10).aspx On Fri, Nov 14, 2014 at 4:34 AM, Gavin Wilby <[email protected]> wrote: > Good Morning, > > > > Thank you very much for this reply, its give a much better insight as to > what is going on. > > > > Firstly, I can verify that the hostname change did indeed work, and the > single laptop that I was configuring is now working correctly with Outlook > Anywhere. > > > > I have however taken on board with what you mentioned below and have set > up a test domain to run through the points that you have rasied. > > > > I have 2 Windows 2008R2 servers, one is a DC and one is a domain member. > CA has been installed onto the DC and Exchange 2010 installed to the member > server. > > > > I have made the change to the DC to allow the CA to allocate SAN > certificates and then run through a SAN cert request on the Exchange server > giving the internal and external host addresses for the cert. > > > > However, it doesn't seem to work as id expect, although it does install > without error, it seems to take the Common name as the certificate that it > produces, so it doesn't work on both internal and external hosts. > > > > I have created the cert as follows (I have obscured a valid ddns address): > > > > > > However this bit seems to fix what is presented to the browser when the > cert is issued: > > > > > > So in this case, the name of the cert is the external host and therefor > doesn't work for the internal network. > > > > What am I doing wrong here? > > > > *Gavin Wilby* > > *IT Support Engineer* > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *ccollins9 > *Sent:* 12 November 2014 16:13 > > *To:* exchange > *Subject:* Re: [Exchange] RE: Self sign certificate and Outlook Anywhere > > > > If it's just one computer you are trying to do this on, you can (probably) > modify the hosts file to trick the certificate name checking. So if the > INTERNAL name of your server is EX01 and the EXTERNAL IP address is 1.1.1.1 > (for example), you can put this in your hostfile: > > 1.1.1.1 EX01 > > DNS resolution always checks the hostfile first, so when you specify the > internal EX01 name in the Outlook Anywhere setup, it will resolve to the > external IP address and the name you used in the hosts file will match the > certificate.. > > > However, you will be well served to get rid of that Self-signed cert and > set it up right. It's the professional way to do things and will ALWAYS > benefit you later down the road when unforeseen scenarios arise. > Self-signed certs are, in general, are a no no. They will inevitably cause > more problems than they are worth, as you can see in your case. Exchange > requires SSL and Microsoft included self-signed certs out of convenience > for admins, so Exchange can get up and running out of the box. > > This really isn't hard at all. If you have a domain CA, then most of the > hard part is over. With an internal CA, the hardest thing you would need to > do is possibly having to make a registry mod of > +EDITF_ATTRIBUTESUBJECTALTNAME2 to allow issuing a SAN certificate from a > Microsoft CA. And like I said, Exchange has it's own certificate request > wizard, so it can't really get any easier. > > > This is how I do it in my domain: > > 1. Launch the certificate request wizard in Exchange > 2. Fill out all the DNS names that I will want to connect to Exchange > 3. Under the Certificate Request File Path section, click Browse to select > a location for the certificate request file, and then enter the file name > you want to use. > 4. After you have the cert request file saved, open in in notepad. Copy > all text > 5. Go to the website of your internal certificate authority (default if > using MS IIS/Certificate Authority is http://servername/certsrv) > 6. Choose Request a Certificate > 7. Choose Advanced Certificate Request > 8. Choose Submit a certificate request by using a base-64-encoded... > > 9. Paste the request into the box, choose Web Server in the drop down > > 10. Submit the request then save the certificate to a file > > 11. Go into Exchange and "finish" the certificate request using the file > that you downloaded in step 10. > > > > > > > http://windowsitpro.com/security/q-how-can-i-enable-my-windows-server-2008-or-windows-server-2003-certification-authority-is > > > > > > > > On Wed, Nov 12, 2014 at 10:01 AM, Joseph L. Casale < > [email protected]> wrote: > > Is the laptop a domain member? If so it implicitly trusts all certs issued > by your domain ca. In that case, create a ucc cert with all your needed > cn's and that's it. > > > > Make the request from a ps console and fulfil it through which ever means > you're comfortable with against your ca. Easiest imho. > > > > jlc > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Gavin Wilby > *Sent:* Wednesday, November 12, 2014 7:01 AM > *To:* '[email protected]' > *Subject:* RE: [Exchange] RE: Self sign certificate and Outlook Anywhere > > > > Hi, > > > > Thanks for the replies, this is all a bit new to me as in the past I have > used SBS where all this is taken care of. > > > > The domain already has a CA, the Exchange already has its own self sign > certs. > > > > Whats going to be the easiest way to achieve this? Can I not simply get > outlook to ignore the certificate, or is this a massive no no? > > > > *Gavin Wilby* > > *IT Support Engineer* > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *ccollins9 > *Sent:* 12 November 2014 13:25 > *To:* exchange > *Subject:* Re: [Exchange] RE: Self sign certificate and Outlook Anywhere > > > > Once you have it figured out where you will be getting the cert, be sure > to issue a SAN cert with both the internal and external website names. SAN > certs allow multiple DNS names on a single cert. The certificate request > wizard in exchange will generate a cert request with multiple names by > default. Also, if you are going to stand up your own CA, there is an > additional step you must perform to allow it to issue SAN certs. > > > http://exchangeserverpro.com/how-to-issue-a-san-certificate-to-exchange-server-2010-from-a-private-certificate-authority/ > > Setup your own CA for your domain, the clients will trust it, then use the > same ca to issue a cert for the right cn that your exch server will use. > > > > Or use startcom to issue a free cert for the server. > > > > jlc > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Gavin Wilby > *Sent:* Wednesday, November 12, 2014 5:29 AM > *To:* '[email protected]' > *Subject:* [Exchange] Self sign certificate and Outlook Anywhere > > > > Hi all, > > > > I have Exchange 2010 that is running with a valid self signed certificate. > > > > I need to set up a laptop with Outlook Anywhere, this seems to work fine > right up until the point it tries to connect. It asks for credentials, and > then immediately says: > > > > There is a problem with the proxy servers security certificate. The name > does not match... > > > > This is because of course that out external name for the server, is not > the same as the internal name. > > > > Is there any work around for this to allow the client to connect? > > > > *Gavin Wilby* > > *IT Support Engineer* > > > > SMP Partners Ltd > > Clinch's House, Lord Street, > > Douglas, Isle of Man IM99 1RZ > > Tel +44 1624 682214 > > Mob +44 7624 480575 > *[email protected] <[email protected]>* > www.smppartners.com > > > > A member of the SMP Partners Group of Companies > > > > SMP Partners Limited, SMP Trustees Limited and SMP Fund Services Limited > are licensed by the Isle of Man Financial Supervision Commission. SMP > Accounting & Tax Limited is a member of the ICAEW Practice Assurance Scheme. > > SMP Partners Limited registered in the Isle of Man, Company Registration > No: 000908V > Directors: M.W. Denton, M.J. Derbyshire, P.N. Eckersley, S.E McGowan, O. > Peck, J.J. Scott, S.J. Turner > > SMP Trustees Limited registered in the Isle of Man, Company Registration > No: 068396C > Directors: A.C. Baggesen, M.W. Denton, O. Peck, J.J. Scott, J. Watterson, > J. Cubbon > > SMP Fund Services Limited registered in the Isle of Man, Company > Registration No: 120288C > Directors: V. Campbell, M.W. Denton, P.N. Eckersley, D.A. Manser, S.E > McGowan, O. Peck, J.J. Scott, R.K. Corkill > > SMP Accounting & Tax Limited registered in the Isle of Man, Company > Registration No: 001316V > Directors: I.F. Begley, A.J. Dowling, P. Duchars, P.N. Eckersley, J.J. > Scott, S.J. Turner > > SMP Capital Markets Limited registered in the Isle of Man, Company > Registration No: 002438V > Directors: M.W. Denton, M.J. Derbyshire, D.F Hudson, S.E McGowan, O. Peck, > J.J. Scott. > > SMP Partners Limited, SMP Trustees Limited, SMP Fund Services Limited, SMP > Accounting & Tax Limited and SMP Capital Markets Limited are members of the > SMP Partners Group of Companies. > > > > This email is confidential and is subject to disclaimers. Details can be > found at: http://www.smppartners.com/disclaimer.html > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ >
