Certificate for Exchange 2019

Hi all,

I have downloaded Certify SSL Manager and trying to generate certificate for Exchange Server. My domain is autotomask.cz, but I need to add alternative names in certificate - primary domain is “mail.autotomask.cz” and alternative names “autodiscover.autotomask.cz, autodiscover.domain.local, mailserver.domain.local, mailserver”.

I ran the “request certificate”, but it produced this output:

2019-09-12 15:02:17.684 +02:00 [ERR] BeginCertificateOrder: error creating order. Retries remaining:1 :: Certes.AcmeRequestException: Fail to load resource from ‘https://acme-v02.api.letsencrypt.org/acme/new-order’.
urn:ietf:params:acme:error:rejectedIdentifier: Error creating new order :: Cannot issue for “autodiscover.peugeot.local”: Name does not end in a public suffix (and 2 more problems. Refer to sub-problems for more information.)

I am using IIS 10 and operating system is Windows Server 2019 Standard (virtual machine).

Can anyone give me an advise please, if it is possible to generate certificate (up to 5 domains?) for these alternative names?

Many thanks in advance.

Hi @robajz

that’s not possible.

You can create a certificate with mail.autotomask.cz and autodiscover.autotomask.cz. But the other names aren’t unique. You can only create certificates with worldwide unique, public domain names.

The end of every domain name must be a public suffix (like .com, .org, .cz …).

One question in addition to @JuergenAuer’s reply could be: what client systems are accessing your mail server using these internal names? Why are they doing this instead of using the public name?

Hi guys,

thanks for quick reply. Our mailserver is accessing only from users, that are domain and externally users (smartphone, tablet, laptop) in the same time.

I thought, that there have to be included the same alternative names like original self-signed certificate on Exchange for seamless connectivity from local and external network/clients?

Yes, if the globally unique names for these servers do not work for internal users then certificates without the local names they expect to use won’t work.

You will need to fix things so that the global names for the servers work even locally (it isn’t necessary for data to travel over the public Internet, only that servers are addressed by a globally unique name) and then you can obtain certificates for those global names and everything will work.

Neither Let’s Encrypt nor a commercial CA is allowed to issue for those local names, if you need to use them for operational reasons you will need to use privately issued certificates to make that work and set everything up to trust those private certificates. But most people can arrange for the global names to work fine inside their organisation’s local networks. NB. It’s the name that needs to work, not the IP address.

1 Like

Hi Tialaramex,

thanks for reply. I thing that adding DNS zones for autodiscover.autotomask.cz/mail.autotomask.cz and pointing to internally Exchange mailserver should be enough. I have done this. Now if I try to ping from internal network to both of these names, it returns internal IP from mailserver.

I suppose this resolves the problem with alternative names?

Yes, you may need to push out config changes or tell staff / users to ensure they use the global name, but once their software is asking for autodiscover.automask.cz (for example) a certificate with the name autodiscover.automask.cz will match that and everything checks out as OK.