SharePoint in Azure – SendGrid Configuration

Recently setup outbound SMTP in an Azure SharePoint farm. There is great documentation ( out there already, but figured I’d share my experiences with it.

Included in Azure is a cloud-based email service called SendGrid. You get 25,000 email credits free a month. Here’s the rest of the pricing:

Once this service is created in your environment (Click the first link to get the walkthrough) you will be assigned a username/password for SMTP relay. Make note of this since you’ll be using it later on.

After the SendGrid service is spun up you still need a way for SharePoint to use this. Pointing the outbound email configuration at will not work because SendGrid requires a username/password. Good thing SendGrid has some good documentation too:

After configuring the SMTP Server feature on the SharePoint server (You could use a separate server for relay, but this was dev so I was playing) I tested first with Telnet (Using the example in the SendGrid documentation) and then with PowerShell to verify everything was working in SharePoint.

The documentation is good so follow that, but I did run into 2 items that weren’t discussed:

  1. Add your domain as an alias domain in SMTP
  2. The IP Address of does not work
    • In SMTP > Right Click the SMTP Virtual Server # 1> Properties > Access > Relay Restrictions
    • Click the Relay button and note that is added (Per SendGrid instructions). This needs to be switched to the IP Address of the Azure server

Here’s the PowerShell example:



SharePoint/Azure ACS Token Signing Certificate. Will you please just sign my tokens?!

Setting up Azure ACS was fun. It’s so easy to get it up/running/connected to SharePoint and you have the instant satisfaction of using Microsoft/Google/Facebook accounts to login to SharePoint. Great success! Note: Microsoft only gives you the UPN claim..which is a unique ID so when users log in it looks gross. Google and Facebook are able to pull in a lot more claims..but Microsoft is more secure in that fashion I suppose.

Anyways there is great documentation out there already on how to get rocking and rolling. Here’s a few I’ve used:

Anyways there isn’t really much documentation out there on the Token Signing Certificate. Most of the documentation out there states to use a self-signed certificate for DEV and get a certificate from a Commercial Certificate Authority for PROD. Alrighty then. Here’s the screen in Azure


Not knowing too much in the ADFS token signing cert space (In the past most environments I have worked with use ADCS or PKI to generate these)  I took to the interwebs.

The reason I was researching is because if I were to put in a CSR for I wouldn’t get it or it would get revoked…I don’t own Companies like Comodo have a DCV (Domain Control Validation) questionnaire built right into the certificate purchasing process. For the self-signed cert you can use whatever you want.

I researched to see if Azure ACS could have a friendly name or DNS CName that we could pull the cert for. NOOPE!

I found a great tool by Steve Peschka that allows you to actually export the token signing certificate right out of ACS. The ACS tenant is actually already an HTTPS site so there is a preexisting cert. SWEEET! It works like a charm too..

This specific client had their heart set on using the commercial certificate authority so I kept trucking.

The certificate for ACS is described in detail here:

Alright I’m still not sure what subject name to use..until I found this forum post:

Frank Lesniak had the answer I was looking for (This was for ADFS, but still applied to ACS):

**I’m just copying his answer in here in case the forum post ever gets deleted

  1. The certificate’s key length should be at least 2048 bits.
  2. Validity period should be as long as possible (given cost), up to 5 years
  3. The signing algorithm should be either SHA-1 or SHA-256. If you need to support ADFS 1.x legacy federation, Windows 2000, Windows XP SP2, or Windows Server 2003, use SHA-1. Otherwise, for best security, use SHA-256. You may need to call your publically-trusted certificate issuer to validate the signing algorithm.
  4. Ensure that the private key is exportable
  5. Subject name does not matter… but something like would be a common implementation.
  6. Key usage does not matter.

The key points being #5 and #6 – ADFS does not care what you name the certificate or what kind of certificate is being used (i.e. code signing, server authentication, client authentication, etc.). My advice would be to generate a certificate however you’d normally feel comfortable doing so. For example, many of my clients use IIS to generate the certificate signing request (CSR), then submit the CSR to the commercial CA. Once you’ve loaded the certificate into the computer store, it should be available for AD FS to use.


In summary – It doesn’t matter! Use or if you’re already rocking a wildcard cert for everything use that. Any X.509 certificate will do…