Exchange Server Pro » Certificates http://exchangeserverpro.com Microsoft Exchange Server News - Tips - Tutorials Wed, 08 Feb 2012 13:00:56 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported? http://exchangeserverpro.com/exchange-2010-wildcard-ssl-certificates http://exchangeserverpro.com/exchange-2010-wildcard-ssl-certificates#comments Mon, 19 Dec 2011 06:36:11 +0000 Paul Cunningham http://exchangeserverpro.com/?p=4360 Question: can I use a wildcard SSL certificate on my Exchange 2010 server?

Answer: Yes, you can.

Often people ask me whether wildcard SSL certificates can be used with Exchange Server 2010, because they have heard that they are either unsupported, not secure, or just not recommended.

What is a wildcard SSL certificate? From Microsoft TechNet:

A wildcard certificate is designed to support a domain and multiple subdomains. For example, configuring a wildcard certificate for *.contoso.com results in a certificate that will work for mail.contoso.com, web.contoso.com, and autodiscover.contoso.com.

The attractiveness of wildcard SSL certificates is that they are usually cheaper than other types of certificates, and they make some Exchange Server configurations easier to manage.

Support for Exchange 2010 and Wildcard SSL Certificates

The support question is a relatively easy one to answer. Yes they are supported from a vendor perspective. One clue for this is that wildcard SSL certificates are an option in the Exchange 2010 new certificate wizard. Microsoft does not make a habit of including options in Exchange Server that will lead you down an unsupported path.

However they are not supported for all scenarios. For example:

  • wildcard certificates can’t be used in conjunction with OCS 2007 (eg for secure communications for UM/OWA integration)
  • wildcard certificates are not supported for older mobile devices such as Windows Mobile 5.0

Security Implications for Exchange 2010 and Wildcard SSL Certificates

The security question is also relatively easy to answer. The common assumption is that wildcard SSL certificates are less secure than other SSL certificates.

Microsoft’s own documentation even references “security implications”.

…many customers are uncomfortable with the security implications of maintaining a certificate that can be used for any sub-domain. A more secure alternative is to list each of the required domains as SANs in the certificate. By default, this approach is used when certificate requests are generated by Exchange.

Verisign/Symantec describes some of those implications here:

  • Security: If one server or sub-domain is compromised, all sub-domains may be compromised.
  • Management: If the wildcard certificate needs to be revoked, all sub-domains will need a new certificate.

However, put those concerns in the context of your Exchange organization. If you’re using a wildcard SSL certificate to secure a single, internet-facing Client Access server then the above issues do not create much concern.

On the other hand if you’re deploying a large, global Exchange organization with multiple geographic entry points for various services, or those services spread over many services, then those issues are of greater concern.

Summary

So in conclusion, yes Exchange 2010 supports wildcard SSL certificates and no they are not necessarily less secure than other certificates.

However, do your due diligence and make sure that the specific support and security scenarios that do exist will not adversely impact your own Exchange 2010 deployment.

Related posts:

This article Exchange 2010 FAQ: Are Wildcard SSL Certificates Supported? is © 2011 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

]]> http://exchangeserverpro.com/exchange-2010-wildcard-ssl-certificates/feed 1 Autodiscover and SSL Warnings during Exchange 2010 Migration http://exchangeserverpro.com/autodiscover-ssl-warnings-exchange-2010-migration http://exchangeserverpro.com/autodiscover-ssl-warnings-exchange-2010-migration#comments Wed, 29 Dec 2010 11:03:48 +0000 Paul Cunningham http://exchangeserverpro.com/?p=2591 This article is an excerpt from the Exchange Server 2003 to 2010 Migration Guide.

When Exchange Server 2010 is first installed many administrators encounter an issue with Outlook clients and SSL certificate warnings, relating to the Autodiscover service and the use of SSL for Exchange Server 2010 by default.

Autodiscover is a service that allows compatible Outlook versions and mobile devices to automatically detect and configure a user’s mailbox settings.  When the Exchange Server 2010 Client Access server role is installed into an Exchange organization it automatically registers the Autodiscover service in Active Directory.

Outlook clients will connect to Autodiscover using SSL (HTTPS), but the new Exchange 2010 Client Access server is only configured with a self-signed SSL certificate when it is first installed.  This can lead to certificate warnings for your end users who are running Outlook 2007 or Outlook 2010.

Outlook Warning for Untrusted SSL Certificate

Outlook Warning for Untrusted SSL Certificate

So you may wish to install the first Exchange 2010 server outside of business hours, so that you have time to resolve the SSL certificate warnings without impacting your end users.

There are three ways to quickly resolve the Outlook SSL certificate warnings in Exchange 2010 environments:

  • Adding the Exchange Server certificate to the Trusted Root Certification Authorities on all of your end user computers using a Group Policy (not recommended)
  • Issuing a new Exchange 2010 SSL certificate from a private Certificate Authority on your network (not ideal, but resolves the issue for computers that are domain members)
  • Purchasing a new Exchange 2010 SSL certificate from a commercial Certificate Authority and installing it on the Exchange 2010 server (this is the best solution, but will of course require you to spend money)

Related posts:

This article Autodiscover and SSL Warnings during Exchange 2010 Migration is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

]]> http://exchangeserverpro.com/autodiscover-ssl-warnings-exchange-2010-migration/feed 5 Exchange 2010 SSL Certificates http://exchangeserverpro.com/exchange-2010-ssl-certificates http://exchangeserverpro.com/exchange-2010-ssl-certificates#comments Sat, 18 Dec 2010 11:13:03 +0000 Paul Cunningham http://exchangeserverpro.com/?p=2535 If it is your first time working with Exchange Server 2010 then you will quickly realise that you need to learn about the relationship between Exchange 2010 and SSL certificates.

SSL Requirements in Exchange Server 2010

Prior to Exchange Server 2007 an Exchange server could be deployed and by default would not require SSL for any of its communications.  The wise move when deploying Exchange Server 2003 (for example) was to install an SSL certificate for IIS and use SSL for external access (eg Outlook Web Access and ActiveSync).  However this was not mandatory and it certainly isn’t unusual to encounter legacy Exchange environments that allow external access over insecure HTTP connections.

For Exchange Server 2007, and then again with Exchange Server 2010, Microsoft changed the default behaviour so that SSL was required for many services, even when they are only used internally.  So a newly installed Exchange Server 2010 server that hosted the Client Access server role would have SSL enforced for services such as:

  • Outlook Web App
  • ActiveSync
  • Exchange Web Services
  • Outlook Anywhere

The administrator could disable that SSL requirement, but again the wise move is to protect Exchange Server 2010 communications with SSL encryption rather than allow them over insecure HTTP connections.

Because the SSL requirement is on by default the Exchange 2007 and Exchange 2010 servers are installed with a self-signed SSL certificate.  This self-signed certificate does the job of securing any SSL connections, however because it is self-signed no connecting clients or devices will trust it, so it is unsuitable for long term use.  The administrator needs to install a new SSL certificate for Exchange Server 2010.

Exchange 2010 SAN Certificates

Administrators who have installed SSL certificates for Exchange before may be familiar with the general process involved.  But they might not be familiar with the SSL certificate requirements for Exchange Server 2010.

In short, Exchange Server 2010 will respond to connections on multiple names.  These names typically include:

  • The fully qualified domain name (FQDN) of the Exchange server, eg ex2.exchangeserverpro.net
  • DNS aliases for external access, eg mail.exchangeserverpro.net or webmail.exchangeserverpro.net
  • The Autodiscover name of each SMTP namespace in the organization, eg autodiscover.exchangeserverpro.net

This makes a standard single-name SSL certificate unsuitable.  Instead, Exchange Server 2010 must be installed with a SAN certificate.

SAN stands for Subject Alternative Names and is a type of SSL certificate that has an attribute that stores additional names for the SSL certificate to apply to.  For example, here is the certificate used to secure Outlook Web App for Microsoft.

Exchange 2010 SSL certificate used by Microsoft

Exchange 2010 SSL certificate used by Microsoft

In Exchange Server 2007 it was possible to make a series of configuration changes so that a single-name SSL certificate would work.  However these changes were complex, especially in larger environments, and the cost to perform and maintain them (in terms of administrative time spent) far outweighed the cost of a genuine SAN certificate from a commercial Certificate Authority.

Where to Buy SSL Certificates for Exchange 2010

There are lots of commercial Certificate Authorities to choose from when buying an SSL certificate for your Exchange Server 2010 servers.  These include:

Each of these providers is different in terms of pricing, licensing and support, so I do recommend that you take a close look and compare them in detail before making a decision.

However my recommendation is to use Digicert’s Unified Communications Certificate, which I like for the pricing, generous licensing terms, and support such as unlimited reissues of the certificate (if for example you forget one of the alternative names the first time you request the certificate).

How to Install an SSL Certificate for Exchange Server 2010

The process to acquire and install an Exchange 2010 SSL certificate is as follows.

  1. Generate a new certificate request using the wizard built in to Exchange Server 2010
  2. Submit the certificate request to your chosen Certificate Authority
  3. Install the issued SSL certificate on the Exchange 2010 server
  4. Assign the new SSL certificate to the appropriate services on the Exchange 2010 server

The complete process is demonstrated in this article:

If you are performing these steps for training or demo lab purposes you may wish to save money and issue the certificate from a private Certificate Authority instead.  If that is the case then follow the steps in this article:

When using private Certificate Authorities you can potentially encounter trust issues that prevent Exchange 2010 from using the certificate.  See this article for details of how to fix this problem:

And finally, in some network environments with restricted access to the internet you may find the new SSL certificate can’t be used by Exchange 2010 because it can’t check it against the certificate revocation list.  If that happens to you follow the steps in this article to solve the problem:

Related posts:

This article Exchange 2010 SSL Certificates is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

]]> http://exchangeserverpro.com/exchange-2010-ssl-certificates/feed 7 SSL Certificate Trust Errors for New Thawte Certificates http://exchangeserverpro.com/ssl-certificate-trust-errors-for-new-thawte-certificates http://exchangeserverpro.com/ssl-certificate-trust-errors-for-new-thawte-certificates#comments Fri, 27 Aug 2010 09:00:46 +0000 Paul Cunningham http://exchangeserverpro.com/?p=2018 If you renew a Thawte SSL certificate or purchase a new one since 26th July 2010 you may encounter SSL certificate trust errors when clients connect to published websites such as Outlook Web Access.

Web browsers will return an error such as:

The security certificate issued by this website was not issued by a trusted certificate authority

On inspection of the certificate being issued by the website you may see this error:

The issuer of this certificate could not be found

This can be confusing for people who assume that any certificate issued by a commercial CA such as Thawte will be trusted by devices and web browsers that people are connecting from, especially when it occurs after renewing an existing Thawte SSL certificate.

Thawte has published the reason for this:

On June 27 2010, in the interest of better security, thawte signed all certificates with a primary and secondary intermediate that need to be installed along with the SSL certificate. Any certificate issued on or after this date requires the primary and secondary intermediate to be installed.

The new certificates are issued by an intermediate CA known as “Thawte SSL CA”.  This CA is not automatically trusted by most web browsers.  Thawte provides instructions for installing the correct certificates on the web server or ISA Server that is publishing the website.

Take note of the final steps, the change may not take effect until IIS or ISA Server are restarted.

If your site still have the chaining error, restart the IIS service. If the problem continues, the whole server needs a reboot to use the new roots.

Related posts:

This article SSL Certificate Trust Errors for New Thawte Certificates is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

]]> http://exchangeserverpro.com/ssl-certificate-trust-errors-for-new-thawte-certificates/feed 1 Exchange Server 2010 and the Benefits of Commercial SSL Certificates http://exchangeserverpro.com/exchange-server-2010-and-the-benefits-of-commercial-ssl-certificates http://exchangeserverpro.com/exchange-server-2010-and-the-benefits-of-commercial-ssl-certificates#comments Thu, 26 Aug 2010 09:00:26 +0000 Paul Cunningham http://exchangeserverpro.com/?p=2014 Petri IT Knowledgebase has published my article on the merits of choosing commercial SSL certificates over self-signed or privately issued ones for Exchange Server 2010.

The business case is clear for purchasing SSL SAN certificates from a genuine commercial certificate authority to use with Exchange Server 2007 and 2010. For an outlay of as little as a few hundred dollars the business receives the benefits of:

  • Far less administrative effort to implement and maintain SSL for Exchange services
  • Compatibility with devices and applications that require connection to Exchange services over SSL
  • Access to Exchange services such as Outlook Web App for remote workers without undermining the security of the network or encouraging insecure behavior by users

Read the full article here.

I frequently encounter customers who request to (in some cases demand to) or have already deployed Exchange Server 2010 with a self-signed or a privately issued certificate.  In 2007 it was possible though cumbersome and frustrating.  In Exchange 2010 it is possible in some scenarios, equally frustrating, and in a few cases seems to be impossible to achieve 100% seamless integration and trust even for domain members (notably Exchange 2010 with Outlook 2010).

Any perceived cost savings by avoiding commercial certificates are a false economy. You spend far more on consultant and administrator effort to implement and maintain the environment with non-commercial certificates.

I generally recommend Digicert’s Unified Communications certificate for Exchange Server 2010 deployments, as I find them easy to deal with and good value.

Related posts:

This article Exchange Server 2010 and the Benefits of Commercial SSL Certificates is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

]]> http://exchangeserverpro.com/exchange-server-2010-and-the-benefits-of-commercial-ssl-certificates/feed 2 How to Issue a SAN Certificate to Exchange Server 2010 from a Private Certificate Authority http://exchangeserverpro.com/how-to-issue-a-san-certificate-to-exchange-server-2010-from-a-private-certificate-authority http://exchangeserverpro.com/how-to-issue-a-san-certificate-to-exchange-server-2010-from-a-private-certificate-authority#comments Wed, 18 Aug 2010 09:00:13 +0000 Paul Cunningham http://exchangeserverpro.com/?p=1898 Exchange Server 2010 makes use of SSL certificates for securing network communications between servers and clients.  An example of this is Outlook Web App (OWA) which uses the HTTPS protocol for users connecting via their web browser (eg https://webmail.company.com/owa).

In this article:


Introduction to SAN Certificates for Exchange Server 2010

Traditionally SSL certificates were issued for a single name (such as the webmail name above), however this is very limiting because once an SSL certificate is bound to an IP address that IP address is not able to accept connections addressed to different names over SSL, or at least not without the name mismatch causing a warning message to the connecting client.

This became an issue for Exchange Server 2007 and 2010 because, depending on the server roles installed, the server may need to accept SSL connections to several different names such as:

  • the server’s FQDN (eg ex3.exchangeserverpro.net)
  • webmail and other published names (eg webmail.exchangeserverpro.net, mail.exchangeserverpro.net, mobile.exchangeserverpro.net)
  • multiple DNS namespaces (eg autodiscover.exchangeserverpro.net, autodiscover.xyzimports.com)

Configuring multiple IP addresses, DNS records, IIS instances, and SSL certificates for all of the possible names in an Exchange organization would be tedious and expensive.

The X.509 certificate standard has catered for this for a long time now with a feature known as Subject Alternative Names.  Basically this allows a single SSL certificate to be configured with a primary name and then multiple alternative names, making it valid for all of the required names that clients and other servers will be connecting to.

SAN certificates are available from most commercial providers however some organizations choose to issue them from their own private certificate authority.  Windows Server 2008 Certificate Services supports SAN certificates by default, however Windows Server 2003 requires the option to be manually enabled first.

Enabling SAN Certificate Support for Windows Server 2003 Certificate Services

You can check an existing Windows Server 2003 CA for SAN support by using the certutil utility from a command prompt.

C:\>certutil -getreg policy\EditFlags
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\ca\Po
licyModules\CertificateAuthority_MicrosoftDefault.Policy\EditFlags:

  EditFlags REG_DWORD = 15014e (1376590)
    EDITF_REQUESTEXTENSIONLIST -- 2
    EDITF_DISABLEEXTENSIONLIST -- 4
    EDITF_ADDOLDKEYUSAGE -- 8
    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
    EDITF_ENABLEAKIKEYID -- 100 (256)
    EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)
    EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)
CertUtil: -getreg command completed successfully.

If there is no EDITF_ATTRIBUTESUBJECTALTNAME2 flag then you can enable it by running the following command.

C:\>certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\ca\PolicyModules\Certifi
cateAuthority_MicrosoftDefault.Policy\EditFlags:

Old Value:
  EditFlags REG_DWORD = 11014e (1114446)
    EDITF_REQUESTEXTENSIONLIST -- 2
    EDITF_DISABLEEXTENSIONLIST -- 4
    EDITF_ADDOLDKEYUSAGE -- 8
    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
    EDITF_ENABLEAKIKEYID -- 100 (256)
    EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)
    EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)

New Value:
  EditFlags REG_DWORD = 15014e (1376590)
    EDITF_REQUESTEXTENSIONLIST -- 2
    EDITF_DISABLEEXTENSIONLIST -- 4
    EDITF_ADDOLDKEYUSAGE -- 8
    EDITF_BASICCONSTRAINTSCRITICAL -- 40 (64)
    EDITF_ENABLEAKIKEYID -- 100 (256)
    EDITF_ENABLEDEFAULTSMIME -- 10000 (65536)
    EDITF_ATTRIBUTESUBJECTALTNAME2 -- 40000 (262144)
    EDITF_ENABLECHASECLIENTDC -- 100000 (1048576)
CertUtil: -setreg command completed successfully.
The CertSvc service may need to be restarted for changes to take effect.

Next you must restart Certificate Services for the change to take effect.

C:\>net stop certsvc
The Certificate Services service is stopping.
The Certificate Services service was stopped successfully.

C:\>net start certsvc
The Certificate Services service is starting.
The Certificate Services service was started successfully.

The server is now ready to issue SAN certificates.

How to Request a SAN Certificate for Exchange 2010

The next step is to create a certificate request from the Exchange server.  You can perform this task from the Exchange Management Shell, or from the console.

For an example of the Exchange Management Console steps see the previous article here.

From the Exchange Management Shell use the New-ExchangeCertificate cmdlet to generate a certificate request.  In this example I am requesting a certificate with the following attributes:

  • A friendly name of “Exchange 2010 Certificate”
  • The server’s FQDN
  • The alternative names of mail.exchangeserverpro.net, autodiscover.exchangeserverpro.net, and webmail.exchangeserverpro.net

I’m also using -GenerateRequest to create a certificate request rather than simply creating a self-signed certificate.

[PS] C:\>New-ExchangeCertificate -FriendlyName "Exchange 2010 Certificate" -IncludeServerFQDN -DomainName mail.exchangeserverpro.net,autodiscover.exchangeserverpro.net,webmail.exchangeserverpro.net -GenerateRequest -PrivateKeyExportable $true

The command will output a certificate request that looks similar to this.

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIEPDCCAyQCAQAwJTEjMCEGA1UEAwwabWFpbC5leGNoYW5nZXNlcnZlcnByby5u
ZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnbhSAM0y26udUo/+8
yvufXrv0AcuzcLYc/9wxNjgOZjmkQUqXEvrxXXrIzCciWL1KDTYjJyVXNkjqCsB3
8tdLWS7tLR/OLj0Px7bsUkTuJKl95DeYGJwxginMjvVKrdxMkPJloWY6i+5ZzHfs
jhK0+bboyaoQMopwnya7AK0H5AfSDUd+hFzbgpX8hdj7hkMVwCS257/fsNkoJbxA
xC7C9Yk06onHypefiz+uTubNULjKBKdtJiyesj6hakyG1tFddsvv6yqwjtAefyVZ
vYWbkSJiXTwALuOrePlt3wGa12ZxqYwl2Mf98gdb2fTq2M6TosPE0PIxoDZvBzV2
IHZxAgMBAAGgggHQMBoGCisGAQQBgjcNAgMxDBYKNi4xLjc2MDAuMjBlBgkrBgEE
AYI3FRQxWDBWAgEFDBtFWDMuZXhjaGFuZ2VzZXJ2ZXJwcm8ubG9jYWwMEEVYQ0hT
RVJWUFJPXEVYMyQMIk1pY3Jvc29mdC5FeGNoYW5nZS5TZXJ2aWNlSG9zdC5leGUw
cgYKKwYBBAGCNw0CAjFkMGICAQEeWgBNAGkAYwByAG8AcwBvAGYAdAAgAFIAUwBB
ACAAUwBDAGgAYQBuAG4AZQBsACAAQwByAHkAcAB0AG8AZwByAGEAcABoAGkAYwAg
/wQEAwIFoDCBhQYDVR0RBH4wfIIabWFpbC5leGNoYW5nZXNlcnZlcnByby5uZXSC
ImF1dG9kaXNjb3Zlci5leGNoYW5nZXNlcnZlcnByby5uZXSCHXdlYm1haWwuZXhj
aGFuZ2VzZXJ2ZXJwcm8ubmV0ghtFWDMuZXhjaGFuZ2VzZXJ2ZXJwcm8ubG9jYWww
DAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUbaUvsgyyRXS0lEHebbnvEqpd7VwwDQYJ
KoZIhvcNAQEFBQADggEBAEQ5GtxZGMf3rw+gGuIj+A8exB7bM2aSg9Z9X6RyNtHX
3iuCHPEOUdkZFSTR3CWoMal1FcH/r1yzCPXKTWDtyMIzi4tiHA/+V2nXALhH6Fbv
c8G0l47iIGlbvuBkBDTxhmLubXgXGAp1dRfwRXd1Vqy0eDe/0LxlUAwq+Kb/RRLw
UaUf3eVrbQUpWNqEmLcorp3mpwnoqAB+GhP+j0ERCquP629xdlHS2yz3fNfn4xGU
Sv/i5FLUf6WmVJu+kjQ50wlh5nE+XiwQmsta0MNUnqIXu9dDXnOpx+VdmuKdEXlh
/zAHMofanelZ/UUBv7mdwMG3E5U17nJ/VoiIAZAygg0=

-----END NEW CERTIFICATE REQUEST-----

Copy the output to your clipboard for the next steps.

Open your web browser and navigate to the web enrollment URL of your Certificate Services server (eg http://ca-server/certsrv).  Click on Request a Certificate.  Note if you are running a Windows Server 2003 CA you may need an update to the web enrollment pages before you can proceed any further.

Choose Advanced Certificate Request.

Choose to Submit a Certificate request…, because we’ve already generated the request on the Exchange server earlier.

Paste the generated certificate request data into the form, and choose Web Server as the certificate template.  Click Submit to continue.

When the certificate has been issued download the certificate file to your Exchange server.


Completing a Pending Certificate Request for Exchange Server 2010

The certificate has been issued and downloaded, and now the pending certificate request needs to be completed for Exchange Server 2010.

Launch the Exchange Management Console, navigate to Server Management, and choose the server that you imported the certificate to.  Right-click the new certificate and choose Complete Pending Request.

Browse and select the certificate file that was downloaded, and the continue to complete the wizard.

The certificate has now been installed and is ready to be assigned to Exchange services.

If you encounter an error message stating that “The certificate is invalid for exchange server usage” then see this article for the solution.

Related posts:

This article How to Issue a SAN Certificate to Exchange Server 2010 from a Private Certificate Authority is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

]]> http://exchangeserverpro.com/how-to-issue-a-san-certificate-to-exchange-server-2010-from-a-private-certificate-authority/feed 21 Exchange Server 2010 “The Certificate is Invalid for Exchange Server Usage” Error http://exchangeserverpro.com/exchange-server-2010-certificate-invalid-for-exchange-server-usage-error http://exchangeserverpro.com/exchange-server-2010-certificate-invalid-for-exchange-server-usage-error#comments Tue, 17 Aug 2010 09:00:41 +0000 Paul Cunningham http://exchangeserverpro.com/?p=1948 A certificate installed on an Exchange Server 2010 server may display the following error message.

The certificate is invalid for exchange server usage

This can occur when the certificate cannot be verified to a trusted certificate authority.  This may occur when the certificate has been issued by a private certificate authority.

To correct the problem you must install the root certificate for the certificate authority.  For a private certificate authority this can be obtained from the web enrollment page (eg http://ca-server/certsrv).

Browse to the web page and click on Download a CA Certificate, Certificate Chain, or CRL.

Click to download either the CA Certificate (if the certificate was issued by a root CA) or the Certificate Chain (if the certificate was issued by an intermediary CA).

Launch a new Microsoft Management Console (Start -> Run, mmc.exe) and add the Certificates snap-in to it, connecting to the Computer Account for the Local Computer.

Navigate to Trusted Root Certification Authorities.  Right-click on Certificates and choose All Tasks and then Import.

Browse and choose the CA Certificate or Certificate Chain that you downloaded earlier.

Place the certificate in the Trusted Root Certification Authorities store.

Complete the import wizard and then refresh the Exchange Management Console, and the certificate should now be valid.

Related posts:

This article Exchange Server 2010 “The Certificate is Invalid for Exchange Server Usage” Error is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

]]> http://exchangeserverpro.com/exchange-server-2010-certificate-invalid-for-exchange-server-usage-error/feed 14 How to Assign an SSL Certificate to Exchange Server 2010 Services http://exchangeserverpro.com/how-to-assign-an-ssl-certificate-to-exchange-server-2010-services http://exchangeserverpro.com/how-to-assign-an-ssl-certificate-to-exchange-server-2010-services#comments Mon, 16 Aug 2010 09:00:43 +0000 Paul Cunningham http://exchangeserverpro.com/?p=1939 After an SSL certificate has been installed on an Exchange Server 2010 server you can assign different Exchange services to use that certificate.

To assign a service to a certificate launch the Exchange Management Console.  Navigate to Server Management, and select the server that has the certificate installed.

If you encounter an error message of “The certificate is invalid for exchange server usage“ see this article for the solution.

Right-click the certificate you wish to assign and choose Assign Services to Certificate.

Click Next to continue the wizard.

Choose the services you wish to assign to the certificate.  In this example I am choosing IIS so that the certificate can be used for OWA, ActiveSync, etc.

Click Assign to execute the change.

When the task has completed successfully click Finish to close the wizard.

The certificate will now appear with the chosen services assigned to it.

Related posts:

This article How to Assign an SSL Certificate to Exchange Server 2010 Services is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

]]> http://exchangeserverpro.com/how-to-assign-an-ssl-certificate-to-exchange-server-2010-services/feed 3 Exchange 2010 Certificate Revocation Checks and Proxy Settings http://exchangeserverpro.com/exchange-2010-certificate-revocation-checks-and-proxy-settings http://exchangeserverpro.com/exchange-2010-certificate-revocation-checks-and-proxy-settings#comments Thu, 29 Jul 2010 09:00:27 +0000 Paul Cunningham http://exchangeserverpro.com/?p=1795 The Microsoft Exchange Team blog posted about an issue people are experiencing in the field in which certificate revocation status check failures prevent you from assigning a certificate to any Exchange services.

If Exchange can’t access the CRL, the certificate status is returned as RevocationCheckFailure by the shell. In EMC this is displayed as The certificate status could not be determined because the revocation check failed.

When a certificate fails a revocation check due to any of the above reasons, the EMC prevents you from assigning the certificate to any Exchange service. Note, this does not impact certificates that have already been assigned to Exchange services. The services will continue to function.

- Source

Two of the causes of this are listed as:

# Network or proxy misconfiguration, or a firewall rule preventing Internet access

# Intentional blocking of Internet connectivity from the server

In a comment on the post I mention using proxy settings to work around the issue.  In other words, if you can use a proxy in Internet Explorer to browse the web when you’re logged onto the server, then you can use this workaround.  However, you need to proceed with caution or you may inadvertently break your management connection to the Exchange server.

Firstly, you can check the server’s proxy settings using the netsh command (proxycfg is no longer available in Windows Server 2008 R2).

C:\>netsh winhttp show proxy

Current WinHTTP proxy settings:

    Direct access (no proxy server).

Note: if you can resolve the direct access issue at your proxy/firewall then that is going to be easier than using this procedure. Otherwise, read on.

If you have the correct proxy settings configure in Internet Explorer then netsh lets you import that configuration to the server.

C:\>netsh winhttp import proxy ie

Current WinHTTP proxy settings:

    Proxy Server(s) :  10.10.10.10:80
    Bypass List     :  (none)

Depending on your environment you may find that this breaks you connection to the Exchange server using either the Exchange Management Console or Exchange Management Shell.

VERBOSE: Connecting to ex1.exchangeserverpro.local
[ex1.exchangeserverpro.local] Connecting to remote server failed with the following error message : The client cannot c
onnect to the destination specified in the request. Verify that the service on the destination is running and is accept
ing requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonl
y IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and co
nfigure the WinRM service: "winrm quickconfig". For more information, see the about_Remote_Troubleshooting Help topic.
    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExc
   eption
    + FullyQualifiedErrorId : PSSessionOpenFailed

The reason for this is that the Exchange Management Shell is trying to make a remote connection to the server, even when you are logged on to the server that you want to manage. This is known as Remote Shell and you can read more about it here.

You can see here that when I launch the Exchange Management Shell on my lab server there are corresponding entries in the IIS log files for the connection that I just made to the /powershell virtual directory.

The reason that this breaks your management connectivity to the server is that the proxy you are using is not correctly configured to let you access local websites. Fortunately you can resolve this by using proxy exceptions on your local Internet Explorer settings.

If I configure Internet Explorer to automatically bypass for local sites, and then re-import the settings to the server with netsh, I see different output.

C:\>netsh winhttp import proxy ie

Current WinHTTP proxy settings:

    Proxy Server(s) :  10.10.10.10:80
    Bypass List     :  < local >

In some cases this still might not work if Internet Explorer is not correctly detecting local sites and bypassing the configured proxy. In that case you can manually specify the proxy exceptions in Internet Explorer.

Again when you re-import using netsh you see a different result.

C:\>netsh winhttp import proxy ie

Current WinHTTP proxy settings:

    Proxy Server(s) :  10.10.10.10:80
    Bypass List     :  *.exchangeserverpro.local;< local >

Alternatively, you can set a proxy configuration for the server that is different to that of your own Internet Explorer settings.

C:\>netsh winhttp set proxy proxy-server="http://10.10.10.10:80" bypass-list="*.exchangeserverpro.local"

Current WinHTTP proxy settings:

    Proxy Server(s) :  10.10.10.10:80
    Bypass List     :  *.exchangeserverpro.local

Again you need to make sure you set the correct exceptions so that management connectivity to the server isn’t broken in the process.

If you can get the proxy settings configured with the right proxy and exceptions you should be able to connect to the server with the console and shell, and also have the server successfully perform CRL checks for your SSL certificates.

Related posts:

This article Exchange 2010 Certificate Revocation Checks and Proxy Settings is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

]]> http://exchangeserverpro.com/exchange-2010-certificate-revocation-checks-and-proxy-settings/feed 11 Export an Exchange Server 2010 Certificate to Exchange 2003 http://exchangeserverpro.com/export-an-exchange-server-2010-certificate-to-exchange-2003 http://exchangeserverpro.com/export-an-exchange-server-2010-certificate-to-exchange-2003#comments Thu, 27 May 2010 09:00:48 +0000 Paul Cunningham http://exchangeserverpro.com/?p=1377 During an Exchange 2003 to 2010 transition a legacy namespace is configured for users who are connecting to Exchange 2003 mailboxes.  The Exchange Server 2010 SSL certificate includes the legacy name in its Subject Alternative Name (SAN) field, but this certificate then needs to also be installed on the Exchange 2003 server.

Export the Certificate from Exchange Server 2010

To export the certificate from Exchange Server 2010 launch the Exchange Management Shell and run the following commands.

First determine the thumbprint of the SAN certificate that is installed.

Get-ExchangeCertificate

Thumbprint                                Services   Subject
----------                                --------   -------
E8D129180C1334D50DBE17A26795BEE0A0AEA9B3  ...WS.     CN=mail.contoso.local, OU=IT Dept, O=Contoso Pty Ltd, L=Brisban...
C5C2B0F04397D1C2C2C9834C48B268EA53F835B4  IP..S.     CN=ex2010

In this example the thumbprint is “E8D129180C1334D50DBE17A26795BEE0A0AEA9B3”.

Next export the certificate to a file by running the following command.

$file = Export-ExchangeCertificate -Thumbprint E8D129180C1334D50DBE17A26795BEE0A0AEA9B3 -BinaryEncoded:$true -Password (Get-Credential).password

A popup dialog appears for you to enter a password to protect the private key. The username field is not important but requires something to be entered in it for the dialog to accept, so just enter “username” and then a strong password.

Next run the following command to generate the file.

Set-Content -Path "C:\Admin\ex2010cert.pfx" -Value $file.FileData -Encoding Byte

Copy the file to the Exchange Server 2003 server.

Import the Certificate on the Exchange 2003 Server

On the Exchange 2003 server launch mmc.exe and add the Certificates snap-in to the console, choosing the “Computer account” context.

Choose Local Computer and then click Finish, Close, and OK to return to the console.

Right-click Personal and choose All Tasks –> Import.  Step through the Certificate Import Wizard choosing the certificate file that was copied from the Exchange Server 2010 server.

Enter the password that you used when the certificate was exported from Exchange Server 2010.

Place the certificate in the Personal certificate store.

Complete the wizard and confirm that the import was successful.

Related posts:

This article Export an Exchange Server 2010 Certificate to Exchange 2003 is © 2010 ExchangeServerPro.com

Get more Exchange Server tips at ExchangeServerPro.com

]]> http://exchangeserverpro.com/export-an-exchange-server-2010-certificate-to-exchange-2003/feed 7