Test Layout

When you install your first Exchange Server 2013 or Exchange Server 2016 server, a certificate with the friendly name Microsoft Exchange Server Auth Certificate is created. This certificate is self-signed and used for OAuth authentication between applications such as Exchange Server and SharePoint. However, it is also used for hybrid deployments between on-premises Exchange Server and Exchange Online. This certificate is unique because it is installed on all of your Exchange servers. The subject for the certificate is "CN=Microsoft Exchange Server Auth Certificate" and does not contain any SAN names with references to specific servers. It also has a 5-year lifetime. Which is just long enough for everyone to forget about it. I suspect that this certificate is due to expire in many organizations soon. Today I got a call from an organization with the following symptoms: Outlook clients were slow to start Outlook clients were not displaying the user's calendar Outlook clients...

This has been popping up for a while, but it's worth pointing out again. When you get a SAN/UCC certificate, the DNS name that you use for the subject (common name) also needs to be in the subject alternative names attribute. For example: Subject: webmail.contoso.com Subject alternative names webmail.contoso.com exch1.contoso.com exch2.contoso.com Autodiscover.contoso.com When you get your certificate from a public certificate authority (CA), most of them ensure that the subject is also added as a subject alternative name. However, some might not and you should watch for it. It's important to note that the Microsoft CA does not automatically add the subject to the list of subject alternative names. So, make sure that you do it as part of your certificate request for your internal CA. The reason you need to do this is because of how web browsers are processing subject alternative names. Web browsers are ignoring the subject if a list of subject alternative names is present. All ...

Have you ever fantasized about using free SSL/TLS certificates for Exchange Server? If so, then this blog post is for you. I’ve always hated the cost associated with SSL/TLS certificates. For what seemed like a pretty basic service some of the certificate authorities (CAs) were charging hundreds or thousands of dollars. You could always set up your own CA, but that didn’t work well with random clients on the Internet because they won’t trust certificates generated by your CA. At the end of 2015, there was a game changing development. Let’s Encrypt started giving away SSL/TLS certificates for free. At the time, the certificates were only for a single name. So, without SAN support, not good for Exchange Server. However, now there is support for SAN/UCC certificates. And, in 2018 they are planning to support wildcard certificates. What’s the Catch? The certificates are free. There is no catch there. But, they do have a short lifetime of 90 days. The short lifetime is to ensure that compro...

Certificate templates for Active Directory Certificate Services (AD CS) have multiple values related to versioning. In the Certificate Templates console, you can see two versioning attributes: Schema Version - This defines the options available in a Certificate Template. If you search for information about certificate template versions (such as https://technet.microsoft.com/en-us/library/cc725838(v=ws.11).aspx ), the reference to different versions is the schema version. These schema versions are consisten across Windows servers. Version - This number is unique for your AD CS implementation. When you modify the template, this version number is incremented. Byron Web Server template: Schema Version 2, Version 100.3 The version number for your certificate templates is composed of a major version number and a minor version number. In this example: Major version: 100 Minor version: 3 When you make any edit to a certificate template, the minor version number is incremented. Even minor edit...

Just recently ran into another issue related to certificate revocation list (CRL) verification. This time it was an Exchange 2010 organization that had been fine when we initially installed the certificates, but now in the Exchange Management Console was showing the currently assigned certificate with a red X and an error message indicating that the CRL for the certificate could not be verified. The certificate was still valid, but the Exchange server couldn't verify that it hadn't been revoked. No clients were affected by this issue. Viewing the certificate on a client accessing OWA showed as valid. Like many organizations, this organization has a proxy between the internal network and the Internet. For the Exchange Servers to verify the CRL, they need to download it from the source specified in the certificate. This had been working, so, what changed? It turns out that as part of troubleshooting connectivity to WSUS from the Exchange servers, the proxy configuration was remov...

Today at a client site I noticed an error in the System log of all the domain controllers: Source: Kerberos-Key-Distribution-Center Event ID: 29 Level: Warning The Key Distribution Center (KDC) cannot find a suitable certificate to use for smart card logons....   This client isn't using smart cards, but there has been some certificate strangeness is the past. So, it's worth investigating. The most common reason for this error is a missing or invalid domain controller certificate. If the organization has an internal CA then it should automatically get a domain controller certificate from that CA. If the organization does not have an internal CA, then you can consider the warning cosmetic and ignore it. In this case, the organization does have an internal CA. In fact, they have an offline root CA and an enterprise issuing CA. Each domain controller has a certificate that is issued from an LDAPoverSSL certificate template. This certificate ensures that all of the domain controller...