Currently we have a certificate from another authority with "*.domain.com" and "sips.domain.com". This is due to RFC 5922, which disallows wildcard certificates for TLS for the SIPS protocol. When we try to create a certificate with the same domains with Letsencrypt, it fails with the error:
Domain name "sips.domain.com" is redundant with a wildcard domain in the same request. Remove one or the other from the certificate request.
This may be true from a HTTPS perspective, although even then it isn't invalid, but it isn't true for SIPS.
In short we'd like to be able to create such certificates.
I am just confirming this is denied by Boulder and not Certbot. This is indeed a Feature Request for LetsEncrypt staff.
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "Error creating new order :: Domain name \"sips.example.com\" is redundant with a wildcard domain in the same request. Remove one or the other from the certificate request.",
"status": 400
}
Edit:
This is stated a bit incorrectly. The RFC disallows matching against wildcards, but the Certificate can have a wildcard. If wildcards were disallowed, your current certificate wouldn't work.
Does it need to be both on one certificate? That seems a little weird to me, though I must admit I haven't looked into SIPS. (Sadly, my current VoIP provider doesn't support TLS, but it's supposedly on their roadmap.) That is, can you get one certificate with the wildcard, and another certificate with the sips. name, and load the SIPS certificate to the SIPS server and the wildcard wherever else you need it?
Is this something that other Certificate Authorities do? If you really need them on one certificate for some reason and other CAs support that, then you can easily use some other ACME-supporting CA just like you would use Let's Encrypt.
Hi @mauritsderuiter, and welcome to the forums! This is a reasonable request, albeit one that we haven't run into at all in the six years since this prohibition was put into place. I can't make any promises about whether or not we'll change anything, but we are discussing it.
Is there a reason that you can't request two different certificates, one with the wildcard for TLS, and the other with the sip subdomain for SIPS? Naively, I would assume that those domains are handled by different tls-terminating frontends/webservers, and having different certificates loaded in different servers should be fairly straightforward.
We're currently using Letsencrypt for our development servers, and some Sectigo PositiveSSL MULTI certificates for our production environment. On production we're indeed combining wildcards and normal subdomains on one certificate. We'd like our dev environments to be as close to production as possible of course, so that's where this feature request is coming from.
This is stated a bit incorrectly. The RFC disallows matching against wildcards, but the Certificate can have a wildcard. If wildcards were disallowed, your current certificate wouldn't work.
Sorry, that's indeed what I meant.
Is there a reason that you can't request two different certificates, one with the wildcard for TLS, and the other with the sip subdomain for SIPS? Naively, I would assume that those domains are handled by different tls-terminating frontends/webservers, and having different certificates loaded in different servers should be fairly straightforward.
SIP clients map a SIP address to a domain result set, consisting of one A record (domain needs to be an explicit subjectAltName) and one or more SRV records (can be covered by a wildcard). This is handled by one backend. Currently, due to our client interpreting the RFC differently, we also add the domains from the SRV records to the subjectAltNames, but we'd like to keep the option open to revert back to a wildcard.