We have a wildcard .pfx file that's of the pkcs 12 convention. We have a vendor that's trying to use it, but it's only working on the whatever.company.com sites (for desktops), and not working on the m.whatever.company.com sites (for mobile). We're assuming this is happening because the wildcard cert is only for *.company.com, and not *.*.company.com.
Do we need to get a new cert created for *.*.company.com or does anyone know of a way to... I don't know... append the additional sub-subdomain to the existing cert? Maybe with keytool and/or OpenSSL .... ?
First, you cannot edit an existing signed certificate without invalidating the signature. And with an invalid signature the certificate will be considered invalid and rejected by the browser. Just imagine if editing a certificate would be possible and the edited certificate accepted by the browser: in this case an attacker could easily modify an existing certificate for its own domain to include any other domain for which he wants to do a man in the middle attack.
Apart from that wildcards like *.*.example.com are not possible, i.e. only a single wildcard is allowed and only in the leftmost label.
Related
I created a certificate in my server for the hostname xxx.lol.example. I want to know if it is possible to create a sub-certificate for the hostname xxx.lmfao.lol.example thanks to the initial certificate?
You can not create "sub-certificate" out of a given certificate.
You need either to request a new separate certificate from some CA for your second name or you should create a new certificate that covers both names, which means putting the second name in the subjectAlternateName part of the certificate (your CA should help you with that).
If you are your own CA as you claim in comment (not clear from your question), then you can just produce whatever other certificate you need.
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".
We are going to need to start supporting multiple subdomains soon (de. fr. etc) so will need to change to a wildcard certificate. This is also good timing with the heartbleed bug.
To change to a wildcard cert I will need to create a new CSR, then when I use this new certificate I am worried that users will be shown warnings in there browsers.
Is there a way to avoid this or have I misunderstood the problem?
No, there will be no error if you turn your domain validated SSL certificate to WildCard SSL certificate, however you need to adjust domain name with new CSR such as for the WildCard SSL certificate, you need to use domain name in the format *.domainname.com
Wish you good luck! Cheers!
What CNAME do I need to generate a wildcard certificate and a hostname certificate in one.
Eg. I can generate *.blah.com and also blah.com, but *.blah.com doesn't match blah.com.
I want to know how I can generate a request to match both.
Thanks.
Since, your certificate is *.blah.com, it will not match to blah.com. It will only match to single level sub-domain of blah.com. Not event to a.b.blah.com.
To match certificate both, you can use subjectAltName extension and mention blah.com in its DNS here. Now, it will also match to blah.com.
To see the effect of subjectAltName, open https://kotak.com and https://www.kotak.com. Browser will open both without any complaint. This is because, in subjectAltName, it has also mentioned kotak.com.
I'm using an SSL certificate from geotrust. I just ordered and installed it this weekend.
However when I try to access my website using https, firefox (and the other browsers as well) the browser warns that the certificate expired a few days ago.
I guess there could be two reasons:
I made a mistake during the installation of the certificate
Geotrust did not sign the certificate properly.
First I want to rule out the second reason considering my browser tells me the certificate expired a few days ago. This does not make sense at all.
Is there a way to extract the expiration date from the certificate?
Thanks!
Sure.... check the certificate in the browser. Click on the not valid warning / broken SSL symbol in the address bar, it should give you an option to view the certificate ;)
TomTom's answer is right on!
Just about any browser will let you see the details of the certificate. There's always a Valid From field and a Valid To field describing the cert's validity period.
Also - check the subject DN and issuer DN. The Subject DN describes your server, the Issuer DN describes the signer. The issuer should be GeoTrust - if the issuer is not GeoTrust, you are not configured correctly, you are likely to be using the cert that came with the web server.