Error seen when attempting to open a web page that’s been secured by https with a certificate.
Your Connection isn’t private
Attackers might be trying to steal your information from {host-name} (for example, passwords , messages or credit cards).
Solution : ERR_CERT_COMMON_NAME_INVALID
This error confused me GREATLY because I generated that certificate, and I was pretty certain the common name was correct, so I double checked.
The truth is this error is VERY MISLEADING, the problem has nothing to do with the certificates Common Name (for the uninitiated, the Common Name or CN is a value within a certificate, that usually holds the ‘resolvable name’ of the website you are visiting i.e. on my certificate (above) you can see that’s www.petenetlive.com).
The certificate giving me the error in the picture above THERE NOTHING WRONG WITH THE COMMON NAME. The real reason that you are seeing this error is because there’s no entry in the Subject Alternative Name (SAN) value in the certificate. So I created a new certificate and copied that same value into both the common name and subject alternative name fields – like so.
If your certificate is publicly signed, then you will need to go back to the certificate vendor and have the certificate reissued with a subject alternative name. However, I issue these certificates internally from my own Certificate Services, so I just needed to add that like so.
Related Articles, References, Credits, or External Links
SSTP gives you the ability to connect to your corporate network from any location that has an internet connection, and is not filtering https. This port is usually open for normal secure web traffic. Traditional VPN connections require ports and protocols to be open for them to work, which makes a solution that runs over TCP port 443 attractive.
Thoughts: While I can see why this is a good idea, Microsoft has basically changed some existing protocols so they work on a port that wont be blocked by most firewalls. This is not a new approach, (Microsoft did it before with RPC over HTTP). I can’t help feeling that the more traffic we push over ports 80 and 443, sooner or later security/firewall vendors are going to statefully inspect/block traffic that isn’t supposed to be on that port. (If you think ‘that would never happen!’ Try running an Exchange Server through a Cisco firewall with SMTP inspection turned on). Anyway, it’s there, I’ve been asked to do a walkthrough, so read on,
Solution
I’ve got a Windows 2012 Server already setup, it’s a domain controller, and is running DNS. You don’t have to have the same server running SSTP/RRAS but in this lab environment that’s what I’m doing. In addition my remote VPN clients will get an IP address from my normal corporate LAN.
1. On the server I have two network cards installed, the first (NIC1) is the normal network connection for the server, the second (NIC2) will be the one that the remote clients get connected to (once they have authenticated to NIC1).
2. Make sure the Internet facing NIC has good comms, and works OK.
3. NIC2 as you can see, does not even need a default gateway.
Windows Server 2012 Add Certificate Services
I’m going to use a ‘self signed’ certificate, if you have purchased one, then skip this section.
4. From Server Manager (ServerManager.exe) > Add Roles and Features > Next > Next > Next > Select > Active Directory Certificate Services.
5. Add Features > Next > Next > Next > Tick ‘Certificate Authority Web Enrolment’.
6. Add Features > Next > Next > Next > Install > Close > From the warning (top right) > Configure Active Directory Certificate Services on this server.
7. Next.
8. Select both Certificate Authority and Certificate Authority Web Enrolment > Next.
9. Next > Next > Next > Next > Next > Next > Next > Configure > Close > Close Server Manager.
10. Open a Microsoft Management Console.
11. File > Add Remove Snap-in > Certificate Authority > Add > Local computer > Finish > OK.
12. Drill down to Certificate Templates > Manage.
13. From the list that appears locate IPsec > Right Click > Duplicate Template.</p:
14. General tab > Change the name to SSTP-VPN.
15. Request Handling tab > Tick ‘Allow private key to be exported’.
16. Subject Name tab > Tick ‘Supply the request’ > Click OK when prompted.
18. Add > Locate the ‘Server Authentication’ policy > OK > OK > Apply > OK > Close the Certificate Template console.
19. From the Certificate templates Folder > New > Certificate Template Issue.
20. Locate the SSTP-VPN entry > OK > Close the MMC.
SSTP Firewall Setup
In this example my server is behind a corporate firewall. If yours is internet facing then you may simply want to add an exception/rules for allowing https/TCP443. My server will ultimately have a public IP address that resolves to its public name (vpn.pnl.com) so I just need to allow the ports in. If your server does not have its own public IP address, then you may need to setup port forwarding instead. You will see later I’m also going to use TCP 80 (normal HTTP) to access my certificate services remotely, so I’ve got that open as well. You may want to access certificate services via HTTPS instead in a corporate environment.
21. On this server I’m simply going to disable the firewall > Start > Run > firewall.cpl {enter} > Turn Windows Firewall on or off > Set as appropriate.
Grant users SSTP VPN/Dial-in rights.
22. Make sure that any user who wants to access the SSTPVPN has had their Dial-in set to ‘allow access’.
Windows 2012 Server Install and Configure RRAS for SSTP
23. From Server Manager (ServerManager.exe) > Add Roles and Features > Next > Next > Next > Select > Network Policy and Access Services.
24. Add Features > Next > Next> Next > Next > Install > Close.
25. Back at Server Manager (ServerManager.exe) > Add Roles and Features > Next > Next > Next > Select ‘Remote Access’.
26. Add Features > Next > Next > Next > Tick ‘Routing’ > Next > Install.
27. Close.
Note: At this point you may see the warning that there are additional steps to take, (to configure routing an remote access), if so you can launch and then close this wizard because we will do it manually.
28. Close Server Manager > Open a new MMC > File > Add/Remove Snap-in > Certificates > Add > Computer account > Finish > OK.
29. Expand Personal > Certificates > All Tasks > Request New Certificate.
30. Locate the SSTP-VPN entry > Click the ‘More information required..’ link.
31. Change the Type to common name > Enter the public name of the SSTPVPN server > Add > OK.
Note: This will be the common name on the certificate, i.e. vpn.pnl.com, which will need a public A/Host record creating for it in your public DNS, (speak to your ISP or DNS hosting company). That way when your remote clients go to https://vpn.pnl.com they wont get an error, (providing you imported the root cert correctly on THAT machine).
35. Right click the server > Configure and Enable Routing and Remote Access.
36. At the Wizard > Next > Next > Tick VPN > Next.
37. Select NIC1, In this case I’m unticking the ‘Enable security’ option, (or is disables RDP and locks the NIC down) > Next.
38. I’m going to use this server so select the bottom option > Next.
39. New > Create a range of IP addresses. (Note: You may need to exclude these from your existing DHCP scope) > OK > Next.
40. Next.
41. Finish > OK > OK > At this point you will see the services restarting.
42. Right click the server > Properties.
43. Security tab > Change the certificate to the one we created > Apply > Yes > OK > Close the console.
Windows Server 2012 – Connect to SSTP from a Remote Client
At this point I have the correct ports open on the firewall, and I’m on a Windows 7 client outside the corporate network.
44. Because we are using a self signed certificate, we need to get the client to trust it. We can give the user the root certificate, or they can connect and download it, here I’m connecting to the Certificate Services web portal. Note: Remember that’s on the same server.
45. Supply your domain credentials > OK > Download a CA Certificate > Download CA Certificate > Save As.
46. Put the certificate somewhere, and call it something sensible.
47. Now launch an MMC on the client machine, and add the certificate snap-in (for ‘computer account’).
48. Drill down to Trusted Root Certification authorities > Certificates > All Tasks > Import > Navigate to, and select the certificate you just downloaded.
Note: If you double click the cert and import it manually, then it gets put into the user accountNOT the computer account, and this will cause you problems. (Error 0x800b0109).
Registry Key Required for SSTP Access
The title is not really true, but as we are using a self signed certificate the client cannot check the CRL for the CA. Even with some purchased certificates you may need to to do this.
49. Open the registry editor and navigate to:
[box]
HKLM > SYSTEM > Current > CurrentControlSet > services > SstpSvc > Parameters
[/box]
50. Create a new 32 bit DWORD called NoCertRevocationCheck and set its value to 1 (one).
Setup a SSTP VPN Connection
51. Open the Network and sharing Center.
52. Setup a new connection or network.
53. Connect to a workplace.
54. Use my Internet Connection.
55. Supply the Internet Address (that matches the common name you used above) > Next.
56. Supply your domain credentials > Connect.
57. Connected successfully.
Note: If it fails at this point, it usually gives you an error code you can Google, or it gives you the option of logging for you to troubleshoot.
58. Just to prove I’m connected, this client can ping the SSTP servers private address.
Related Articles, References, Credits, or External Links
If you would like to obtain a digital certificate either from your own CA, or from a public certificate vendor, you need to submit a certificate signing request (csr) first.
Solution
Note: I’m making the assumption you have already installed the Web Server (IIS) role on your server.
1. Windows Key+R > iis.msc {Enter} > Select the servername > Server Certificates.
2. Create Certificate Request > Fill in the details > Next.
Note: The Common name will be the name on the certificate, e.g. If this certificate is going to secure https://sitea.domain.com then the common name would be sitea.domain.com.
3. Note: For IIS generally 1024 bits will be fine, but I suggest you use a 2048 bit length > Next.
4. Select a location to save the request and give it a sensible name > Finish.
5. Here is your certificate request in PIM format, you can copy and paste this text into your certificate request.
In the following procedure I’m using Window Server 2012, and Windows 8 Enterprise, I am NOT configuring for Windows 7 so I don’t need to worry about PKI and certificates. (Other than the one the direct access server uses for https identification).
I’m not adding in any Application or Infrastructure servers, this is just a basic run through on setting up Direct Access to get you up and running.
Solution
Step 1 Create Direct Access Group
You can of course accept the default of allowing access to the domain computers group, but I would like to tie things down a little further.
1. Server Manager> Tools > Active Directory Administrative Center > Select the OU (or create one) where you want to create the group.
2.Give the group a sensible name like DirectAccessComputers.
3. Remember when you try and ‘add’ members it will by default NOT have computers listed you will need to add them in.
6. Or from Server Manager > Tools > Add Roles and Features.
7. Simply add in ‘Remote Access’ and accept all the defaults.
Step 3 Configure Remote Access
8. Once installed launch Remote Access Management.
9. Run the getting stated wizard.
10. Deploy Remote Access Only (I’m not deploying VPNs).
11. Select how the server will be deployed, mine has a single NIC and I’m going to port forward TCP Port 443 (https) to it from the firewall. Enter its Publicly addressable name > Next > Finish.
14. Remove the domain computers and add in the group we created above. Untick the ‘mobile only’ option.
Note: Force Tunnelling means that the remote clients will access the internet though YOUR corporate network. This is only a good idea if you have internet filtering, AV or NAP that you want to take advantage of. (It’s literally the exact opposite of split tunnelling).
15. Remote Access Server > Edit.
16. Select an existing Cert or create a new one > Next.
17. Remember I’m just using Windows 8, if you see the Windows 7 box and think “ooh I’ll tick that!” Then you need to start using certificates > Finish.
18. Finish.
19. Review the settings > Apply.
20. Operation Status.
21. Press Refresh until all the services are green.
Step 4 Configure Clients
The title is a misnomer and to be honest there is no configuration to be done, but they have to get the settings through group policy, so log then onto the domain.
22. A quick simple check is to run the following command;
[box]
Get-DaConnectionStatus[/box]
Note: If you get an error message make sure you are not using Windows 8 Pro see here.
23. The client knows it’s ‘inside’ the LAN, because it has a Name Resolution Policy Table and it can see your internal DNS, you can prove this with the following command;
[box] Get-DNSClientNrptPolicy[/box]
Step 5 Test Clients Externally
Note: Before you proceed your Direct access server needs to be publicly available via the name you specified on the certificate in step 11, and needs to have https open to it.
25. Whilst out on the internet you can test your remote client by first making sure it’s pointing to the correct place;
[box]netsh interface httpstunnel show interface[/box]
This should give the the URL that is on the certificate you specified in step 11, when you ping it by name you should expect a reply (unless ICMP has been blocked by your edge device).
26. And to prove that the client knows it’s NOT on the corporate LAN execute the following;
[box]netsh dnsclient show state[/box]
27. So If i try to ping the internal FQDN of my Direct Access server it should respond (Note its IPv6 address will respond this is normal).
Note: Here I’ve only setup the one server, you can add more Infrastructure and Application servers in the Remote Access Management Console.
28. Because I can resolve that, I can access resources on that server like UNC paths.
29. To access shared resources.
Step 6 Monitoring Remote Access Clients
30. Back on the Direct Access server, you can see the remote clients under ‘Remote Client Status’.
31. Right click each one for a more detailed view.
Related Articles, References, Credits, or External Links
Seen when trying to connect the Windows 8 mail client to Exchange 2010 (that is using a self signed certificate).
Error
Unable to connect. Ensure that the information you’ve entered is correct.
Solution
This is a right pain! My Exchange 2010 server is using a self signed certificate, and even though the Windows 8 client trusts my domain CA, and it has imported the cert that Exchange is using, it still would not work.
I Know the cert is OK, Outlook Web Access and Outlook work fine without reporting any certificate errors. I even put the CAFQDN in the Windows 8 hosts file in case it needed to see that (because I read that the problem is related to the client not being able to see the CA’s certificate revocation list).
The only way I found to cure this problem, and let me successfully connect to Exchange, is to remove the self signed certificate and use a purchased certificate.
When you setup SBS2008 (and Exchange 2007) it creates and uses a self signed certificate, which is fine. But by default it only lasts two years. The best option is to buy a proper certificate, but if you simply want to generate a new one here’s how to do it.
Solution
1. Here you can see your certificate has expired.
2. Normally you need to access your certificate services web enrolment console to carry this procedure out. But when you navigate to https://localhost/certsrv you will probably see this:
Server Error in Application “SBS WEB APPLICATIONS”
Note: If web enrolment is installed, and you still cant access certificate services (CertSrv) then click here
3. You are seeing this error because certificate services might be installed, but the “Certificate Authority Web Enrolment” role service is not, you can add it from server manager.
4. Select it and follow the on screen prompts > Go and have a coffee.
5. Now you should be able to access the web front end.
6. To get a certificate we need a certificate request, you can write the powershell yourself like so:
[box] New-ExchangeCertificate -GenerateRequest -Path c:mail_yourpublicdomianname_co.csr -KeySize 2048 -SubjectName “c=gb, s=Your State COunty, l=Your City, o=Your Org, ou=Your Department, cn=mail.yourpublicdomianname.com” -PrivateKeyExportable $True [/box]
OR simply go here and let the good folk at Digicert do the heavy lifting for you.
7. Now you have the code, generate the request, on the Exchange server > Start > All Programs > Microsoft Exchange Server 2007 > Exchange Management Shell > Execute the command you copied above.
8. This will dump the request on the C: drive (because in your command above you set the path to C:mail_yourpublicdomianname_co.csr) Locate it and open it with Notepad. Then select and copy ALL the text (copy as shown no extra spaces etc.)
9. If you have closed it down log into certificate services web access. Select “Request Certificate” > We will be submitting an advanced certificate request.
10. “Submit a certificate request by using………..”.
11. Paste in the text you copied at step 8, change the certificate template to “Web Server” > Submit.
12. Download the certificate.
13. Save it somewhere you can find it (the root of the C: drive is easiest, as you are going to be referencing it in a command shortly).
14. Job done, close the browser window.
15. Back at the Exchange Management Shell issue the following command:
It will ask you for the thumbprint > paste it in > when prompted enter “A” to confirm all.
17. That’s the job finished.
SBS2008 Unable to access Certificate Services
I’ve seen this on a few SBS2008 Servers, when you install the web enrolment service it installs into the servers “Default Web Site”, For any other Windows/Exchange combo that’s fine but SBS likes to do things its own way. It creates another web site called “SBS Web Applications” and uses that. That’s fine, but only one can be up and running at a time.
CertSrv The Webpage cannot be found
1. Warning: You are about to stop things like OWA briefly. From Administrative tools launch the Internet Information Services (IIS) Manager > Locate the SBS Web Applications site and click stop (right hand column) > then select the Default Web site and start it.
2. Select the CertSrv virtual directory.
3. You can now browse via http/https and this will open the site in your default browser. Don’t forget to stop the Default website, and restart the SBS Web Applications site when you are finished.
Related Articles, References, Credits, or External Links
Part Three – Deploying Exchange 2013 On a ‘Greenfield Site’
KB ID 0000730
Problem
In part one and part two we looked at what to consider, and what you need to be doing before you reach for the install DVD. Now we will run through a complete Exchange deployment on a fresh site with no existing mail system.
I’ve already written extensively about the hardware, software and environment requirements for Exchange 2013. Please run through the following article before you start.
With a fully updated Windows Server 2012, that is a domain member your main three pre deployment tasks are to install the following pieces of software.
9. Select the roles required, I’m just having one server so I’m selecting both > Next.
Note: Current Microsoft thinking is to NOT separate out roles like you did with Exchange 2007 and 2010, if you deploy multiple servers deploy multiple roles.
10. Set the install path for the Exchange program files. If you change form the default, and you are deploying multiple Exchange servers, try to keep the path the same for all > Next.
11. Select an Organization name > Next.
12. Select if you want to disable the built in malware protection or not.
Note: Malware protection is now based on Forefront. Only consider disabling this if you plan to deploy some third party malware/AV scanning software.
13. You should get a warning telling you that once complete you will not be able to install Exchange 2010 > Next.
14. Setup will progress (Approx 45 minutes).
15. When done > you can tick the box and launch the ‘Exchange Admin Center’. BUT At this point I would run a full Windows update and reboot the server.
Exchange 2013 Post Install Configuration Tasks
1. To launch the new ‘Exchange Admin Center’, navigate to https://localhost/ecp.
2. Sign in.
Enter the Exchange 2013 Server Product Key
3. Navigate to Server > {Server-Name} > Enter Product Key.
4. Type in your 25 character product key > Save.
5. Read the warning > OK.
6. Windows Key+R > services.msc {Enter} > Locate and restart the ‘Microsoft Exchange Information Store’ service.
Exchange 2013 Create a Default Send Connector
Without configuring a send connector, your outbound/internet destined mail will sit on the outbound queue with the following error.
7. Navigate to > Mail flow > Send Connector > Add.
8. Give the connector a name and select ‘Internet’ as it’s use > Next.
9. By default it will select where to send the email based on the DNS name of the recipient, however some people route all their mail via a smart host, (this can be a server or IP address at your ISP or a mail filtering provider). If you use a smart host you will probably already know, in most cases you will want the default option of ‘MX record associated with recipient domain’ > Next.
Exchange 2013 Adding a Domain Name as an Accepted Domain
14. Whilst in the Mail Flow section > Accepted Domains > Add.
15. Give the entry a name > Type in your domain name > Save > Repeat for any additional domain names.
Adding New Email Addresses to the Default Email Address Policy.
16. Whilst in the Mail Flow section > email address policies > With the default policy selected > Edit (pencil icon).
17. Email address format.
18. Add.
19. Select the domain > Select the name format > If this email address will be the default/reply address then select the bottom tick box > Save > Repeat for each additional email address you want to apply to your users, but only one can be the reply address.
1. Create a folder on the destination drive/volume.
2. First see where the database is now. From within the Exchange admin center (https://localhost/ecp) > Servers > Databases > Select the database to be moved > Edit (pencil icon).
3. Take a note of the database path, and the database filename (filename.edb).
4. Launch the Exchange Management Shell.
5. Execute the the following PowerShell command;
Answer Y to the questions (or A for all).
6. Now you can check that the database has mounted, and is in its new location.
Exchange 2013 Apply for, and Install a Third Party Certificate
1. From within the Exchange admin center (https://localhost/ecp) > Certificates > Add.
2. Self signed certificates are literally more trouble than they are worth, you need to BUY A CERTIFICATE! > Next.
3. Give the request a name > Next.
4. We don’t want a wildcard certificate > Next.
Note: A wildcard certificate is a certificate that has a name like ‘*.domain.com’.
5. Select the Exchange Server > Next.
6. Select the internet Outlook Web App and Edit (pencil icon).
7. Type in the publicly addressable domain name of the Exchange Server > OK.
8. Set the public name of the Autodiscover service > OK > Next.
9. MAKE SURE that the OWA public name is IN BOLD as this will be set as the ‘common name’ on the certificate > Next.
10. Type in your details > Next.
11. Select a share to save the certificate request in > Finish.
Note: This share must already exist, with the correct permissions, if in doubt watch the video above.
12. Now you should have a pending request.
13. Take the certificate request that it has generated (in PIM format), and send that to your certification authority, the link below will take you straight to the correct certificate you need;
14. Once complete and you have received your new certificate back again > Select the pending request > Complete.
15. Supply the path to the certificate > OK.
16. Now you need to assign Exchange services to the certificate> with it selected > Edit (pencil icon).
17. I’m not using unified messaging or POP, so I’ve just selected SMTP, IMAP and IIS > Save.
18. Yes to overwrite the existing certificate.
19. Now lets make sure its worked, open https://localhost/owa > it will error because the URL is wrong > continue to this website.
20. Open the certificate and check it is correct. (here mine has a common name of mail.petenetlive.com).
Exchange 2013 Setting up ‘Split DNS’ for your Exchange Certificate
Note: You only need to set this up if your private/internal, and public/external domain names are different.
21. To avoid annoying DNS and certificate errors on your internal network, your best bet is to setup ‘Split DNS’. Create a forward lookup zone that matches your PUBLIC domain name. Then inside this zone create an A/Host record for mail that points to the internal IP of your Exchange Server. And another for Autodiscover that points to the same IP address.
WARNING: If you do this, and have a www.yourdomainname.com website hosted externally, you will find that your internal users can no longer get to it! If that happens create an additional A/Host record for a host called www and point its IP address to the publicIP address of your website (you may also need an FTP entry if you use that externally as well).
22. Now open a web browser and navigate to the public name of your mail sever, this time it SHOULD NOT ERROR.
Exchange 2013 Test Mail Flow
1. Log into OWA, and send a test email to an internal email address (on a new deployment you probably only have Administrator as a mailbox, so send yourself an email).
2. Then send a test email out to a public email address.
Note: If this fails, check it has left the Exchange Organization by looking at the Queue Viewer.
3. Once you know mail is flowing out test mail in, if this fails make sure you have an MX Record and an A/host record pointing to your Exchange 2013 Server.
Also ensure that TCP port 25 (SMTP) is open to the Exchange Server, (or ‘port forwarded’ to it). And if not add TCP 443 That’s HTTPS, so it is also open/forwarded for OWA, Outlook Anywhere and ActiveSync to work.
Related Articles, References, Credits, or External Links
Exchange 2010 installs with it’s own (self signed) certificate. To stay free of security errors and warnings, the best bet is to purchase a “publicly signed” digital certificate and use that.
The following process uses the Exchange Management console to create a CSR (Certificate Signing Request). Then what to do with the certificate, when it has been sent back to you.
What used to be a fiddly job, is now very simple to do, setting up Outlook Anywhere (formally known at RPC over HTTP) takes about 10 minutes.
What is Outlook Anywhere?
This is a system that lets you connect Microsoft Outlook to to your Exchange server over the web, this means you can connect to to your email, calendaring and tasks etc, without the need for a VPN connection.
Solution
Outlook Anywhere with Exchange 2007 (Exchange 2010 Skip to Step1)
If you plan to deploy Outlook Anywhere with Exchange 2007 there is an additional step you need to carry out before you start. From server manager > Feature > Add Features > Add in the ‘RPC over HTTP Proxy’ feature before you start. (Note: you DONT need to do this if you are running SBS 2008).
Step 1 Configure Exchange
1. First we need to turn it on: from within the Exchange Management, expand Server configuration > Client Access > Select the server in the central pane > Select “Enable Outlook anywhere” in the action pane.
2. Enter the publicly addressable name of your Exchange server, for this example I’m using NTLM authentication > Enable.
Note: The external host name is the address that you would type into a browser to contact the Exchange server i.e. for Outlook Web Access http://mail.domaina.com/owa. This would mean the public name is mail.domaina.com. This name must be the Common Name (CN) on the Exchange server’s digital certificate.
3. Take heed of the information, nothing’s going to work for 15 minutes (Even Exchange is telling you to apply the cup of coffee rule) > Go and have a hot milky beverage.
4. Look at the timestamps and the clocks, this one took 14 minutes (for once the dialog had it spot on!) You should see Event ID 3007, 3003, 3004,(all these are normal) and finally,
5. Event ID 3006 > Outlook Anywhere is up and running on the server. (Note: you will NOT see this on an Exchange 2007 Server, see the second screenshot).
Note: To Access from Outside your network the public name of the Exchange server (in this case mail.domain.com), needs TCP port 443 (HTTPS) open to it, or “Port Forwarded” to the Exchange server.
Note2: To work internally make sure that mail.domaina.com resolves to the INTERNALIP address of the Exchange server.
6. You may also want to execute the following command. Particularly if you use SBS, which has a habit of setting remote.publicdomain.com as the default outside name.
[box] Set-WebServicesVirtualDirectory –Identity ‘EXCHANGE-MAILEWS (Default Web Site)’ –ExternalUrl https://mail.domain.co.uk/ews/exchange.asmx[/box]
Step 2 Configure Outlook for Outlook Anywhere
1. In this example I’m using Outlook 2010 and the mail profile/account has NOT been setup, if you already have an account edit it, select “More Settings” and jump to number 4.
Note: To support Outlook Anywhere you need a minimum of Outlook 2003 SP2
2. If you are setting up your Outlook client internally, the autodiscover service should fill in the details for you.
3. If it auto configures the settings for you, tick the box to manually configure server settings.
4. More Settings.
5. Connection Tab > Tick “Connect to Microsoft Exchange Server using HTTP” > Click “Exchange Proxy Settings”.
6. Put on the URL (Public name of Exchange – see step 1 number 2) > I’m using NTLM authentication you may be using basic, if you don’t know, check with your IT department, or try each one.
7. Security Tab > Ensure “Encrypt data between Microsoft Outlook and Microsoft Exchange” is selected.
8. Restart Outlook – you may be asked for your username and password again this is normal.
Related Articles, References, Credits, or External Links
Cisco PRSM gives you the ability to import certificates into it, but like other Linux distros does not give you the tools to generate the actual certificate request. The documentation tells you to use OpenSSL to this. I was just about to fire up a CentOS box when I remembered I did something similar for VMware 5.5 not so long ago, would the same procedure work here? Yes it did, and it’s a lot easier than growing a ginger ponytail, donning sandals and firing up Linux.
Solution
The following procedure was carried out on Windows Server 2012 R2. I want my certificate to have a common name of prsm.petenetlive.com (change your configs and commands accordingly).
2. Accept all the defaults and it should install to C:OpenSSL-Win32 go there, and in the bin directory make a backup of the openssl.cfg file.
2. Open the original openssl.cfg file and delete everything out of it, then paste in the following text, replace the values in red with your own, and save the file.
Don’t worry if it says it cant read the openssl.cnf file
4. If you look in C:OpenSSL-Win32bin directory you will see the CSR (certificate request) has been generated.
5. Open the .csr file with notepad and copy all the text, (this is a request in PEM format). This is what you will give to your CA to request the certificate, copy that to the clipboard.
6. Connect to your Certificate Authority web enrollment portal > Request a certificate.
7. Advanced certificate request.
8. Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
9. Paste in the PEM text you copied to the clipboard > Set the certificate template to ‘Web Server’ > Submit.
Note: Your CA may have a different template for web server certificates, if so use that one. If you don’t see web server either it’s not been published, or your user does not have rights to the certificate template.
10. Choose ‘Base 64 encoded’ > Download > Save the cert in the directory you were using earlier (you will see why in a minute) > I give it the same name as the common name on the certificate so I saved it as prsm.petenetlive.com.cer
11. Here it is, but there is still a problem with it, PRSM needs the certificate in x509 format, (it isn’t). But OpenSSL-Win32 can convert it for us.
How to Convert a Windows .cer file to an x509 .crt file
cd C:OpenSSL-Win32bin
openssl x509 -in prsm.petenetlive.com.cer -out prsm.petenetlive.com.crt
[/box]
13. Now it looks better, for PRSM we need this file AND we need the .key file, (not the one that ends in xxx-orig.key!) In the example below I’ve kept everything neat so the other file i need is prsm.petenetlive.com.key, (third one down).
14. Connect to PRSM > Administration > Server Certificates > Browse and select both files.
15. Install and Restart Server.
16. Restart.
17. Refresh your web session and you should now be using the correct certificate.
Related Articles, References, Credits, or External Links
