While trying to connect Outlook (2016) to an Office 365 email account;
We can’t connect you
It looks like we can’t connect you to one of our services the moment. Please try again later, or contact your helpdesk if the issue persists.
0xCAA70010
{ADFS-URL}
Solution
This was happening because my ADFS server was using a ‘self-signed’ certificate (i.e. not a purchased one). This should NEVER be done in a production environment, but this is my test network, (so I refuse to spend money on certificates for testing etc!)
I cured the problem by simply importing/trusting the CA Certificate from my internal Certificate Services CA server, (that issued the ADFS servers certificate).
If you see this on a production server, with a publicly signed certificate, check that the ‘problem’ client does not need a Windows Update, to update its trusted CA Certificates, or that your certificate simply hasn’t expired, and you ‘forgot’ to renew it. If so;
In vSphere 5 and earlier versions this was not a ‘fun’ job at all, many times I sat down to do it, and lost the will to live. Now there’s a nice new tool built into vCenter that does ‘most’ of the hard work for you. Here I’m using the vCenter appliance but the tool is also available on the Windows version.
For my certificates I’m using Microsoft Certificate Services. I’m going to issue a ‘Subordinate CA’ certificate to my vCenter Appliance, then it can issue signed certificates to each of its services.
Solution
Make sure you have published a ‘Subordinate Certification Authority’ certificate template.
Connect the the vCenter appliance using SSH and enable ‘shell’
[box]
shell.set --enabled True
shell
[/box]
Create a directory to store our certificates and requests in, then launch the certification-manager tool.
The app will launch, and present you with a bunch of options.
Select option 2 > No we don’t want to use the configuration file > enter your logon information, (administrator@vsphere.local and password) > Enter all the items required for the certificate request.
Choose option 1 (Generate Certificate signing request) > Specify the folder you created above, (/root/SSLCerts) > Two files will be generated > Enter ‘2’ to exit.
The files;
vCenter 6.5
vmca_issued_key.key (the private key)
vmca_issued_csr.csr (the request)
vCenter 6.0.0
root_signing_cert.key (the private key)
root_signing_cert.csr (the request)
Now we need to get the CSR (signing request).
[box]
cat /root/SSLCerts/vmca_issued_csr.csr
OR
cat /root/SSLCerts/root_signing_cert.csr
[/box]
Copy the certificate PEM file.
Open the web enrolment portal of your certificate services server, (https://server.domain.com/certsrv) > Request a certificate > Advanced Certificate Request > 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 > Paste in the PEM text > Remember to use the Subordinate Certificate Authority template > Submit.
Base 64 Encoded > Download Certificate > Save it somewhere you can find it, and give it a sensible name!
Now download the Base 64 version of your CA certificate from the main page of your certificate services website, (press ‘back’ a few times).
Now back in your SSH session, change to your SSLCerts directory, and create an ’empty’ file to paste our certificate information into.
[box]
cd /root/SSLCerts/
touch vmca_signing_cert.cer
vi vmca_signing_cert.cer
[/box]
Open the certificate for the vCenter Appliance in a text editor, and PASTE INBELOW it, the text from the Root-CA certificate. Then copy ALL the text to the clipboard, and go back to the SSH session.
Paste the text you have coped into the open ‘vi editor’ page (Press I, then P) > Save and Exit (Press Esc > :wq {enter})
If you ‘ls’ (thats list short, or dir if you are a Windows type), you will see you now have a .CSR, a .KEY and a .CER file. (the names of which vary between version 6 and 6.5).
Version 6.5
Version 6.0
Launch the certificate-manager application again > Option 2 again > No (again) > Login (again) > ‘N’ > Option 2 (Import custom certificate(s)) > Give it the path to the certificate file > Then the path to the key file.
This is pretty much part two of the last article I wrote, so make sure you have the vCenter CA setup as a Sub CA of your Microsoft Certificate Services Deployment. See the following article;
Now we take the next step, and replace the certificates on the ESXi hosts.
Solution
Note: Joining the ESXi Hosts to the domain is not essential, it just makes things a little smoother. Ensure the host is set with the correct hostname and DNS settings.
Join the host to your domain.
vCenter 6.5
vCenter 6.0
Supply the domain name and suitable credentials.
Set the domain members to trust the vCenter CA Certificate. Back in part one we issued a SUB CA cert to the vCenter. Now I’m going to get a copy of this certificate, and get all my domain members to trust it, (and by definition all the certificates it issues). Browse to the vCenter https address > And open the certificate properties (click the padlock) > Certificate path > CA > View Certificate > Install Certificate.
Local machine.
I’m going to put it in Intermediate Certificate Authorities.
Then open an MMC console, and add in the certificate snap-in for Local Computer > Intermediate Certification Authorities > Certificates > Locate the ‘CA’ Certificate.
Export the certificate.
DER encoded is fine.
Save it on the root off the C: drive with a sensible name.
Open an administrative command window, and issue the following commands;
Now you will see the domain members start to get the CA certificate, (either in Intermediate or Root, depending on the command you issued above).
Meanwhile back in vCenter Web Client > Right click each host > Certificates > Refresh CA Certificates > Then Refresh Certificate.
WARNING: You may see the error below; if you do, it’s a bug don’t panic, there is a fix published on VMware Support. But if you wait 24 hours and attempt to renew the certificates it will work without an error.
A general system error occurred: Unable to get signed certificate for host: esx-host.your-domain.pri. Error: Start Time Error (70034).
You should see something like this;
If you browse to each ESXi host on https it should connect without errors or warnings.
Related Articles, References, Credits, or External Links
There is no valid SMTP Transport Layer Security (TLS) certificate for the FQDN of <domain>. The existing certificate for that FQDN has expired. The continued use of that FQDN will cause mail flow problems. A new certificate that contains the FQDN of <domain> should be installed on this server as soon as possible. You can create a new certificate by using the New-ExchangeCertificate task
Cause: One of the server installed certificates that has the “S” attribute (SMTP) has expired, If its the main certificate for the serve then you will need to replace it. However this is common on server that still have a copy of the certificate they self signed and used when exchange was first installed. So you are not using them anyway.
Solution
I’m assuming that the certificates that have expired are not the ones you are using in anger, lets make sure.
1. To see what certificates are being used for what. Launch “Exchange Management Shell” > Issue the following command;
[box] Get-ExchangeCertificate [/box]
2. Above you can see I’ve got three certificates and they all are being used for SMTP, lets make sure they are all in date.
3. Click Start > mmc {enter} > File > Add/Remove Snap-in > Certificates > Add > Select “Computer account” > Next > Accept the default of “Local computer” > Finish > OK > Expand Certificates > Personal > Certificates.
4. Look down the expiration date section and you can see which ones are out of date, compare this list to original one, and you can see which certificates need removing.
5. You can remove the expired certificated from here by right clicking > Delete.
6. OR, you can delete the certificates from within powershell with the following commandlet;
[box] Remove-ExchangeCertificate {thumbnail of certificate} [/box]
7. Then press Y and {Enter} to confirm.
8. Either when you are finished you should be looking more like this.
Note: Without an SMTP certificate with the FQDN of the server you may see Event ID 12014.
Error:
Microsoft Exchange couldn’t find a certificate that contains the domain name <name> in the personal store on the local computer. Therefore it is unable to offer the STARTTLS SMTP verb for any connector with a FQDN parameter of <name>. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for every connector FQDN.
You can simply create a self signed certificate with the FQDN of the server and import it, then set it for SMTP (Note: it WONT overwrite the one you are using). Or click here.
Related Articles, References, Credits, or External Links
Certificate enrollment for Local system failed to enroll for a DomainController certificate with request ID N/A from {hostname}{name of CA}(The RPC server is unavailable. 0x800706ba (WIN32: 1722)).
Solution
Note: The pertinent information in the Event ID 13 above is 0x800706ba there are Other causes of this Event ID make sure yours is the same.
In my case I had an Exchange server that was using a certificate that had been “self signed”. And the Root CA that signed the certificate had been ungracefully removed from the domain. Take a note of the Root CA name from the Event ID error shown arrowed).
1. Launch Active Directory Sites and Services” > Select the top level object > View > Show Services Node.
2. Expand Services > Public Key Services > AIA > Delete the “Problem CA”.
3. Then select “Enrollment Services” > Delete the “Problem CA”.
If you have a New CA (in this example you would have seen it in step 2), then DO NOT perform the next two steps!!!
4. Providing you DONT have a CA now, select “Certificate Templates” and delete them all.
5. Providing you DONT have a CA now, select “Public Key Services” and delete the NTAuthCertificates item.
6. To tidy up, (On the server logging the error) run the following command:
[box] certutil -dcinfo deleteBad [/box]
7. Finally on the server logging the error run the following command to update the policies:
[box] gpupdate /force [/box]
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
This ensures that traffic that is sent over an RDP connection to a server is protected by TLS/SSL Encryption. IT DOES NOT stop clients connecting to an RDP server if they do not have a trusted certificate. If you need that level of security, that should already be done by 802.1x.
Solution
Create an RDP Certificate Template
1. On the domain CA Launch the Certification Authority Management Console > Certificates Templates > Right click > Manage.
2. Locate, and make a duplicate of, the Computer template.
3. General tab > Set the display and template name to RemoteDesktopSecure.
5. New > Name=SSL Secured Remote Desktop > Object Identifier=1.3.6.1.4.1.311.54.1.2 > OK.
6. Select the policy you have just created > OK.
7. Remove the other policies, so only the one we have just created remains > OK.
8. Security tab > Ensure that the the computer groups you want to apply the template to, are selected for Read and Enroll. (Below I’ve put three examples, firstly I create a group for my servers, secondly I just apply it to my domain controllers, or lastly I allow all Domain Computers). How you want to apply this depends on you.
9. Issue/Publish the new certificate template.
Create a GPO to secure RDP access with Certificates.
10. From the Group Policy Management Console, create (or edit) a GPO and give it a sensible name.
Locate the ‘Server authentication certificate template’ policy.
12. Enable it and set the template name to RemoteDesktopSecure > Apply > OK.
13. In the same location, locate the ‘Require use of specific security layer for remote (RDP) connections’ policy.
14. Enable the policy and set the security layer to SSL (TLS 1.0) > Apply > OK > Exit the policy editor.
15. Link the GPO to an OU that contains the servers you want to apply the policy to.
16. You may need to wait a short while, but eventually the servers will get their certificates.
Note: This view is simply ‘Microsoft Management Console’ with the ‘Certificates (Local Computer)’ snap-in added.
17. To prove it’s working, try connecting from a client that does not trust your Domain CA, and you should see an error something like this.
Check What Certificate RDP Is Using
You can check the thumbprint of the certificate the server is using. Windows Key+R > Regedit {Enter} > Navigate to;
[box]
HKEY_LOCAL_MACHINE
> SYSTEM > CurrentControlSet > Control > Terminal Server > WinStations > TemplateCertificate
[/box]
You can check this with the actual Certificate> Windows Key+R > mmc {enter} > File > Add/Remove Snap-in > Certificates > Local Computer > Open Certificates > Personal > Certificates > Locate the certificate you ‘Think’ RDP is using and you can compare its thumbprint with the registry key you found above.
Or you can execute the following PowerShell command to get the RDP certificates thumbprint;
Originally we had TS Web in 2003, and while I had a little play with it, it basically just gave you RDP over web, which would have been good if it ran over HTTP or HTTPS, but it didn’t. Also, as anyone who has ever done a complex Google search for “/tsweb” will testify, left a nice big security hole in to your servers.
With the release of Server 2008 we got TSWeb 2008, this was a whole different beast, and the web portal was very similar in operation to Citrix Web Presentation Server.
With Server 2008 R2, Terminal Services became Remote Desktop Services, so if you only have a couple of clients (i.e. don’t need an application farm etc,) then this might be just what you need, and buying licences for Remote Desktop Services is a LOT cheaper than buying the same licences plus Citrix licences that are about three times the price per seat.
I originally wrote this for TSWeb 2008, and updated it for Remote Desktop Services 2008 R2, I’ll leave the older information at the bottom for anyone who is still running 2008 R1.
Solution
Setup Remote Desktop Services Web Access on Server 2008 R2
1. In this example I’ve got a fresh server which is a domain member, and I’m going to put the Licensing server and the same box. From server manager (ServerManager.msc) >Roles > Add Roles > Next > Remote Desktop Services > Next > Next.
2. Everything is going on one server, you may want to split roles up in a larger production environment, but here we are adding Remote Desktop Session Host, Remote Desktop Licensing, Remote Desktop Gateway > Remote Desktop Web Access > Next > Next.
Note: When selecting role services, you will be prompted to “add required role services”, please do so.
3. I’m choosing the least secure method (choose this if you have older client running older versions of the RDP client) > Next > Either select a Licensing model (per user or per device, or select configure later) > Next.
Note: The licensing model chosen MUST match the CALS that will be in the licensing server. (If you are unsure configure it later, then you will have 120 days grace period to sort it out).
4. Add in which user groups to want to allow access to the host server > Next.
5. Decide which options you want to allow, to enrich your end user experience > Next > I dont need a scope as all my RD Servers will be 2008 R2, it you have TS servers as well you will need to configure a scope > Next.
6. If you already have a certificate you can select it here, I’m going to manually import the certificate into IIS at the end of the procedure > Select “Now” to configure the access policies > Next.
7. Add in which user groups you want to allow through the Remote Desktop Gateway > Next.
8. At the RDCAP screen, I’m just going to use passwords > Next > Then at the RDRAP screen, I’m going to allow connections TO ANY computer > Next > Next > let it install the Network Policy Server component > Next.
9. Install > Then go and have a coffee.
10. When completed, select yes to reboot which it will do (twice).
11. After you log back into Windows the installation will complete > Close
Import and Enable a Digital Certificate in IIS7
12. Start > Administrative tools > Internet Information Services Manager > Select the {server-name} > Server certificates > From here you can either create a certificate request, or complete a request, and import a certificate.
13. Here is my certificate with the “friendly name” WebServer.
14. To enable my certificate right click the “Default Web Site” (Assuming that’s where you have RDWeb installed) > Edit Bindings.
15. Select HTTPS > Edit > And select your SSL certificate > OK.
16. Restart the website (or run “iisreset /noforce” from command line).
18. Anything that needs configuring will have a yellow warning triangle, or a red cross over it. First you will see it’s complaining that there are no computers in the “TS Web Access Computer ” group.
19. That’s just a LOCAL group on the server itself, launch ServerManager >Configuration > Local Users and Groups > Groups > Locate the group.
20. Add in your groups as required > Apply >OK.
21. Back in the RemoteApp Manger > Check the RD Session Host Server >Settings (on the menu on the right) > Make sure the PUBLIC name (which will be the CN on your digital certificate) is displayed NOT the LOCAL FQDN of the server. You can also tick the option (shown with the arrow) to display the RDP shortcut to your users on the web portal. > Apply > OK.
22. To do the next step, you need to have the applications you want to give to your users, actually installed on the server. > Either right click at the bottom, or select “Add RemoteApp Programs”.
23. Follow the wizard, and select the programs as required.
24. Click refresh > Make sure there’s no more red/yellow warnings > Close RemoteApp Manager.
25. To test it, connect to your server on https://{servername}/RDWeb and log in.
26. You applications should be shown, give them a test, here I’ll launch Outlook.
27. I already have Outlook configured on the Remote Desktop Server so mine just opens (your users will need to setup Outlook, if they don’t have a profile on the RD server already).
Setup Terminal Services Web Access on Server 2008 R1
1. Start > Server Manager (or Start > run > CompMgmtLauncher.exe (Enter) > Add Roles..
3. Select the application you require or browse to its Executable > Next. >
4. Finish.
Connecting from a client
1. On a Client PC open internet explorer > Navigate to http://{serverIP or name}/ts > Note: If you do not have ActiveX enabled and the latest RDP client you may see this error.
2. There’s your applications > simply select one.
3. Enter your login credentials.
4. Wait for the application to deploy.
5. And there you go 🙂
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.
Out of the box Exchange 2007 and 2010 comes with a “Self Signed” digital certificate. That’s OK for getting you up and running but your Outlook clients may start to see the error below.
Error:
Security Alert
Information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the sites security certificate.
The security certificate was issued by a company you have chosen not to trust. View the Certificate to determine whether you want to trust the certifying authority.
Solution
You have a number of options to stop this error.
Option 1 (This is WHAT YOU SHOULD DO!)
You should purchase a certificate signed by a trusted certification authority, these used to cost a fortune, but if you shop around you can pick them up very cheaply.
Option 2 (Free, and handy if you don’t have a lot of clients)
It still amazes me that people with pay out for a new server, and Exchange, but then refuse to buy a certificate? But if your reading this then that might well be you. You can choose to trust the certificate that’s being presented to you. You carry out this procedure on each Outlook client. If you have a lot of Outlook clients then skip to options 3 and 4).
1. First, start up Outlook and get the error message on the screen.
Install your own certification authority, and sign your own Exchange certificate. Great if you already have a CA, though it’s a mess about just to solve this problem.
Related Articles, References, Credits, or External Links
