We have a local Exchange server that we are testing out. We also have a wildcard certificate and wanted to use that certificate for Exchange. We got the certificate installed correctly, but we get an error notice when Outlook connects to Exchange.
The error is:
"exchange.office.domain.com
...
The name on the security certificate is invalid or does not match the name of the site"
When I "View Certificate...", I see the correct certificate, issued to "*.domain.com"
I am not sure if the problem is that the * does not work for exchange.office, that is how we have the network setup however.
Does anyone know how we can get Exchange to work with the wildcard certificate (we do not want to buy another certificate for testing), or if the problem is the multi-host in the FQDN, how we can get around that?
Thanks for your thoughts.
I don't know if Exchange has their own rules, but for HTTPS a certificate for *.example.com does not match foo.subdomain.example.com. A wildcard is only valid for a single label and only for the leftmost label. See also https://security.stackexchange.com/questions/52478/why-does-firefox-not-trust-this-us-government-ssl-certificate/52479#52479
how we can get around that?
Your only options are to either change the hostname (or provide an alias) to match the certificate or to change the certificate to match the hostname.
Wildcard SSL Certificate can only secure first level domain name.
If you have purchased wildcard SSL certificate for 'domain.com', using wildcard you can secure '*.domain.com' sub-domains. (First Level)
If you have purchased wildcard SSL certificate for ".domain.com", using wildcard you can secure '..domain.com' sub-domains. (Second Level).
As you wants to secure "exchange.office.domain.com" , it is a second level domain name option. So to secure it you need to buy Wildcard SSL certificate for "office.domain.com".
Related
I am currently using CloudFlare and recently added an SSL certificate to my script.
Before hand, I added an A record (proxied with CloudFlare) that pointed to my TS IP. It worked like this: ts.domain.net:PORT
However, after I added the SSL cert, it doesn't seem to work anymore.
If it matters, my main site IP is also (of course) proxied under CloudFlare
Thanks!
Every certificate contains one or more Subject Alternative Names. You can use the certificate only on domains that are listed as SAN within the certificate, as long as you don't have a wildcard certificate that can be used on a all subdomain, eg. *.mydomain.net.
Therefore for your TS server you need a certificate that contains the SAN ts.domain.net. If your current certificate is only for domain.net you need another certificate for your Teamspeak subdomain.
My web server's FQDN is foo.bar.com
It is aliased and most commonly accessed at baz.bar.com
I had a SSL certificate generated by our netsec guys and I installed it to the server and enabled the site. Now I am receiving Error code: SSL_ERROR_BAD_CERT_DOMAIN because the certificate is only for foo.bar.com, not baz.bar.com
How can I get this resolved?
The hostname in the URL you use to access a site must match a subject of the certificate. This means if you want to access the site as bot baz.bar.com and foo.bar.com you either need a certificate which contains both or need two certificates and serve the certificate based on the request name. In the last case the client must support SNI if both names point to the same IP address.
I am going to use an SSL certificate on my chat application based on XMPP(ejabberd) which is hosted on an IP.
So, I will be using the IP as the common name when I am generating my SSL certificate. But the server that has everything hosted on it, refers to the IP using a hostname as abcd.yourserver.net.
Therefore, I am confused as to if I have to use the IP or this weird hostname while generating my SSL certificate and if in future I decide to use a domain name instead of the IP for my application, will I have to buy a new SSl certificate or can I regenerate the old one. Also, can I change the type like wilcard or single certificate?
P.S. I have never bought an SSL certificate, so forgive me if the question is newbish.
When generating an SSL certificate for an XMPP server, you have to use the domain name of your XMPP service.
I have domain mydomain.com. I need use subdomains such test1.mydomain.com, helloworld.mydomain.com. These subdomains just host names in IIS bindings for my main site. Users of my sites can add subdomains. Is it possible to use one certificate for all subdomains and main domain? How can I test it with self signed sertificate?
Thanks!
Typically a standard SSL Certificate is issued to a single Fully Qualified Domain Name only, which means it can be used only to secure the exact domain to which it has been issued. With the Wildcard SSL option activated you expand what's possible by receiving an SSL Certificate issued to .domain.com. So if you apply for ".mydomain.com" it will secure "anything.mydomain.com"
Not quite sure on how to do it with self-signed certificates. Hope this info helps.
You will need to use a wild-card certificate eg
http://www.rapidssl.com/buy-ssl/wildcard-ssl-certificate/index.html
Once all the domains are in effect alliasses of the main domain there should be no problem here.
I dont know much about self signing certificates - except that they seem to be more trouble than they are worth. for less than $10 you can get a cert (not wildcard) from someone like CheapSSLs and test with this if you want - it will just throw an error about the name of the domain not matching the certificate
Is it possible to get one SSL certificate *.mysubdomain.example.com and mysubdomain.example.com, I need because I am using 2 IP on my dedicated server but now I am moving to Azure on azure we can't add two https endpoint. or other solution for azure I need two https endpoint
You can purchase a wildcard SSL certificate that encrypts requests made to *.example.com. This will work for an unlimited number of third-level subdomains. To include the second-level (example.com) and forth-level (subforthlev.subthirdlev.example.com) or higher subdomains, you must find a certificate authority (CA) that allows you to include multiple subject alternate names (SANs) in the wildcard certificate. Each non third-level domain needs to be manually added as a SAN.
Edit: I've used DigiCert's wildcard certificates several times and I have not come across a browser or device that did not have their root certificate installed (see their compatibility list). DigiCert wildcard certs allow you to secure an unlimited number of subdomains regardless of the domain level. Excerpt from first link:
DigiCert WildCard ssl certificates are unique in allowing you to secure ANY subdomain of your domain, including multiple levels of subdomains with one certificate. For example, your WildCard for *.digicert.com com could include server1.sub.mail.digicert.com as a subject alternate name.
If you want your certificate to be valid for both *.mysubdomain.example.com and mysubdomain.example.com, it needs to have a Subject Alternative Name entry for both.
The *.mysubdomain.example.com wildcard expression doesn't cover mysubdomain.example.com.
These rules are defined in RFC 2818 and clarified in RFC 6125:
If the wildcard character is the only character of the left-most
label in the presented identifier, the client SHOULD NOT compare
against anything but the left-most label of the reference
identifier (e.g., *.example.com would match foo.example.com but
not bar.foo.example.com or example.com).
In practice, that's indeed how most browsers react.
It's however quite likely that a CA issuing a wildcard certificate for *.mysubdomain.example.com will also add a SAN for mysubdomain.example.com. Check with your CA.
You can use multiple SSL certificates and add them all to the same endpoint by automating the process of installing the certificates on the machine and add HTTPS bindings to IIS.
IIS 8 (Windows Server 2012) supports SNI, which enables you to add a "hostheader" to the HTTPS binding.
I'm a Microsoft Technical Evangelist and I have posted a detailed explanation and a sample "plug & play" source-code at:
http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/