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.
Related
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.
I followed the excellent write up how-do-you-sign-certificate-signing-request-with-your-certification-authority to create my own self-signed cert. I set the SAN for *.pro and *.pro.example.com
If I hit the web02.pro.example.com all works fine.
When I hit web02.pro it doesn't work:
curl --cacert cacert.pem https://web02.pro/version.html
curl: (51) SSL: no alternative certificate subject name matches target host name 'web02.pro'
web02.pro and web02.pro.example.com both resolve to the same machine, and that machine is set up to answer to both names.
The cert I generated shows:
X509v3 Subject Alternative Name:
DNS:*.pro, DNS:*.pro.example.com
Is there anything limit to using a not read TLD for a self-signed cert?
Many clients not only check that the hostname against all names in the certificate, but also only allow wildcards which are not too permissive. This means that wildcards like *.pro.example.com or *.example.com are considered valid while wildcards which only specify the top-level domain like *.pro are considered invalid and will not be included in the validation process.
This reason for this is that below a top-level domain you will usually find lots of domains with different owners. A wildcard certificate for *.pro would thus include domains from different owners which should better not be possible.
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".
A PCI Compliance scanner is balking that the self signed SSL certificate protecting secure access to Plesk Panel contains a name mismatch between the location of the Plesk Panel and the name on the certificate, namely the self-signed cert's name is "Parallels" and the domain to reach Plesk is 'ip address:8443'.
So I figured I would go ahead and get a free SSL certificate to try to fiddle with this error. But when I generated the certificate I used my server domain name as the site name when I generated the certificate. So if I visit 'domain name:8443' all is fine, no ssl warning. But if I visit 'ip address:8443' (which I believe is what the scanner does) I get the certificate name mismatch error, Digicert's ssl checker says that the certificate name should be the ip address.
Can I even generate a certificate whose common name is the ip address? I am tempted to say I should just do what the PCI scanner accepts, but what is really the correct common name to use? Anybody run into this issue before?
You can try a Subject Alternative Name extension for the IP address. Also, you can keep "Parallels" as the Common Name, and add a Subject Alternative Name extension for the DNS name, which should be the preferred match (i.e. higher precedence than Common Name.)
Can I even generate a certificate whose common name is the ip address?
No, you shouldn't. While this may work with some browser, this will fail with clients that are compliant with the HTTPS specification:
In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.
If you want to use an IP address in a certificate, you must have it in as a Subject Alternative Name (of type IP address, not DNS). You can check this question for details on how to do this.
However, more importantly, it sounds like in your case you don't need to use the IP address at all.
The purpose of certificate name verification is to check that the identity in the certificate matches the identity as requested by the client. (Reverse lookups or other names don't matter.)
The fact that you've already configured your system for your domain name and that it works when using the name means that it's already configured properly. It sounds like your giving your scanning tool the IP address of what you're trying to scan (which isn't what the clients would normally use): make it use your host name instead. That's what the scanning tool should try to compare anyway.
Can I even generate a certificate whose common name is the ip address?
(Thanks Bruno for pointing to right solution) There is enough to set subjectAltName in CSR.
IFAIK there is no such option in Plesk, but here good instruction for openssl http://apetec.com/support/GenerateSAN-CSR.htm
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!