We have followed installation guide for Sitecore 9.0.1 and installed it on our dev machines. We have used the same approach also on TEST machine. This TEST machine is also standalone installation which means we have everything in one server to minimize configuration and deployment time. TEST environment is only used for demo purposes so only sporadically.

As TEST is same as DEV machine, we have used self-signed certificate.

TEST is in Azure and was created as one VM where we have Sitecore and XConnect instances, SQL Server + SOLR.

We have two "problems" that don't look good during demo sessions:

A. Server url is something.cloudapp.net

B. We can see warning that site is not secured. That is due to self-signed certificate

My questions:

  1. What are requirements for SSL certificate?
  2. When requesting SSL certificate which parameter should correspond to our something.domain domain that we are planning to buy to be complaint with Sitecore 9?
  3. After we buy something.domain domain how this should be set up in Azure to make redirection work? We want to always see our custom domain not cloudapp.net domain. Should we just set new certificate in binding in IIS for https and make config changes with thumbprint?
  4. Is it sufficient to buy SSL certificate for sc site or we need to buy one for xconnect and solr? Can we use same certs also there or we need to have separate SSL certs for them?

1 Answer 1

  1. The only site that needs to be https is the xConnect service, though your Sitecore site is extremely highly recommended to be https as well. Since you are an XP0 configuration where everything is on a single machine, you can create a self-signed certificate to use with the xConnect service. However, you will also need a SSL client certificate for your Sitecore site to authenticate with the xConnect service site. This is a separate certificate (that can also be self-signed) whose thumbprint must match the configuration set in the xConnect site.
  2. You can create a certificate request directly in IIS for a SSL certificate. Some companies that sell certificates accept these requests, others have their own way for you to specify the content of the certificate. This will be dependent on who you're ordering the certificate from.
  3. After you purchase your domain, you will want to configure your DNS to point to the public IP address of the virtual machine. If you are using a dynamic IP address, you can create an A record to the *.cloudapp.azure.com URL with your new domain name.
  4. This will be dependent on your configuration. The only certificate that will need to be externally validated as it will be user-facing is the SSL certificate used for https on the Sitecore site if you are using https on your Sitecore site (which you most definitely should). Solr will require a SSL certificate for https as well, however, this should not be externally accessible so self-generation of a cert with an internal CA should be fine - someone more security-oriented can correct me on this. Same goes for xConnect's https SSL certificate. The client authentication SSL certificate for xConnect will be shared across all servers which will need access to xConnect. This should be the same cert as it will need to match the thumbprint specified on the xConnect service. There currently (as of 9.0.1) no support for multiple thumbprints to validate against.
  • The install docs/Sitecore support are pretty clear about self-signed certificates not being allowed in production environments. Also worth noting that the single cert really only makes sense in XP0 architectures; XP1 would have a different client cert per xConnect service. Mar 13, 2018 at 14:02
  • Unless something has changed recently, XP1 servers will still need the same client cert if they're connecting to the same xConnect instance as it matches a specific thumbprint. Also, it has been established in the original question that this is not a production environment, but yes, you should never use self-signed certs in a production environment. Mar 13, 2018 at 23:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.