Tag Info

Hot answers tagged

29

Look closely at the certificate: X509v3 Subject Alternative Name: DNS:*.googleusercontent.com, DNS:*.blogspot.com, DNS:*.bp.blogspot.com, DNS:*.commondatastorage.googleapis.com, DNS:*.doubleclickusercontent.com, DNS:*.ggpht.com, DNS:*.googledrive.com, DNS:*.googlesyndication.com, DNS:*.storage.googleapis.com, DNS:blogspot.com, DNS:bp.blogspot.com, ...


27

There's some inconsistency between SSL implementations on how they match wildcards, however you'll need the root as an alternate name for that to work with most clients. For a *.example.com cert, a.example.com should pass www.example.com should pass example.com shouldn't pass a.b.example.com may pass depending on implementation Essentially, the ...


18

RFC 2818 in "3.1. Server Identity" states that Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. So yes, it's the fact that it's two levels of subdomains that is the problem.


9

At the time of this writing I believe that with respect to deciding where to purchase a wildcard SSL certificate, the only factors that matter are the first year's cost of an SSL certificate, and the pleasantness of the seller's website (i.e. user experience) for the purchase and setup of the certificate. I am aware of the following: Claims about ...


7

You can make certificates pretty strong, however not all browsers support encryption that strong. 16384 bits is valid, though getting a commercial certificate authority to issue one is another matter. Fundamentally, wildcart certs are no different than non-wildcard certs from a technical point of view; they just have a "*." in their subject line. Update: ...


7

It is possible that your certificate chain is not complete. You might need to add the RapidSSL CA Bundle. to your certificate. In Apache you have the option SSLCertificateChainFile. Set this to the path where you saved the RapidSSL CA Bundle. Another option is to add the chain certificates to your own by appending them to your certificate like this cat ...


7

Yes you can buy a wildcard SSL and use that over multiple servers. There is no technical reason not to, although certain vendors will try prevent you from a marketing perspective. Using the same certificate in multiple servers means you'll have to copy the private key as well which in some key stores is not as trivial as it sounds. In apache and mod_ssl ...


6

First, SAN certificate = UCC certificates. They are both just certificates with the SubjectAltName field. Second, a wildcard of ..domain.com won't work in most browsers. You will either need to get two wildcard certificates (one for *.sandbox.domain.com and one for *.domain.com) or get a wildcard certificate for *.domain.com and have your SSL provider put a ...


6

Two things you can do: Verify the intermediate chain Clean up the intermediate chain Verify the intermediate chain As the error seems to indicate, there is something off about your intermediate certificate chain. You should check where you got your certificate from and that you got the correct intermediate bundle. You should verify the "hash" and ...


6

Since this question's been rudely resurrected, something that hasn't been mentioned is the reissue of certificates. I didn't really understand what this meant until heartbleed came along. I'd assumed that meant they'd give you a second copy of your original certificate, and I wondered how disorganised one had to be to need that service. But it transpires ...


5

You're correct, the root domain needs to be an alternate name for it to validate.


5

To my knowledge, there is no difference between wildcard and normal certificates. So long as you have full control over domain.com's DNS, then there's no reason not to use a wildcard. In fact, I would recommend it in your case. What are your specific concerns with them? (IMO, Redirects such as the one you suggest are always a bit of a fudge when they're ...


5

From RFC 2818: Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single ...


5

You only need to have a certificate that matches what users will have in the address bar (the hostname they are connecting to), so if all access is going to be via server.domainname.com, you'll only need the certificate to cover that. If you attempt to access either server directly over SSL - e.g. by actually typing https://server1.domainname.com in a web ...


4

Is there a particular reason you are adding them to /etc/hosts? If the hostname resolves, that should be plenty for a more general purpose. I like the directory structure you are using and that is very similar to any approach I would use. Additionally, I recommend specifying separate ErrorLog and CustomLog files for each subdomain. Zoredache makes a ...


4

I dont think its even possible to use localdomain entries on non self signed SSL's however one possible work around for you, why not make the internal access available on internalcrm.contoso.com and do some internal dns setup that points that domain to the internal crm machine and then it can be part of the wildcard SSL without any problem whatsoever?


4

The solution was to provide a certificate chain. When you upload a SSL certificate to AWS, it requires a private and public key. It also has a 3rd field for the certificate chain that is optional. I didn't include the certificate chain originally and that caused the browser to not be able to verify the certificate. I got my certificate chain from the ...


4

SSL certificates are not based on region, neither are they linked to specific IPs. You can use them wherever you want. However, you could be facing a third party that will ask you to buy in your currency (i.e: check their conversion rate between euro and $USD. It's... interesting). Your CSR/CRT will have to declare your country, through the "SUBJECT: C=" ...


4

You would need another ssl certificate for *.dev.mysite.com per http://www.ietf.org/rfc/rfc2818.txt Section 3.1 Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered ...


4

I would do something like this (tested with nginx 1.4.2, seems to work): server { listen 127.0.0.1:443 ssl; server_name site1.example.com; include common.conf; location / { proxy_pass http://127.0.0.2:8081; } } server { listen 127.0.0.1:443 ssl; server_name site2.example.com; include common.conf; location / { proxy_pass ...


4

If you want a certificate to handle example.com and www.example.com you should NOT use a wilcard certificate, because *.example.com does not match example.com. Instead you need a certificate which has like example.com as the common name and then add www.example.com to subject alternative names. Also, if you want https://example.net or https://example.biz ...


4

When I had a certificate issued for a domain, my provider helpfully added www as a Subject Alternative Name, like so: (pardon my horrible censoring) So the answer is, not usually. Most providers do this automatically. Ask your provider if you're not sure or if the certificate they do issue you lacks this field. Note: This is the very basic certficate ...


3

Installing the certificate is sufficient for you to recognize it and consider it valid, it's not sufficient for you to claim the certificate as your own. You need to install the corresponding private key as well. If you have the certificate and key as a .p12 file, you can follow Microsoft's directions.


3

You can use a wildcard certificate with multiple subdomains across multiple IP addresses. While there is no technical limitation, often Certificate Authorities have licensing restrictions on thier usage.


3

From a technical aspect it would be just as secure. You would still be using the same encryption you would with a non-wildcard cert. What is it that they are saying is less secure?


3

The fact that the certificate didn't show up in the Configuration Tool presents the first problem. If the cert is installed correctly then it should show up on that list. Where in the certificate store did you place the certificate? It should be in the Local Computer's certificate store under Personal > Certificates. You'll also need to make sure that ...


3

It doesn't work that way: the SSL handshake happens before HTTP, so the name on the certificate will get evaluated in the browser before you can redirect or do anything else inside the nginx configuration.


3

find a different company. a place with a support staff telling you to 'just google it' is a company that does not deserve your business. also, this link might be able to help you.


3

The contents of that green bar come from the certificate itself, which you will have to get reissued to change it. The certificate's O attribute in the subject (organization), along with the C attribute (country) determine what is displayed. If they are absent, it will simply display the primary subject domain name from the certificate. Also, the name ...


3

As noted in the question, Namecheap must have an issue with the "Reissue" feature available in the dashboard. To reissue the cert directly from RapidSSL, visit this page and enter your info: https://products.geotrust.com/orders/orderinformation/authentication.do I had the same issue after I accidentally deleted my key file and csr for the original request, ...



Only top voted, non community-wiki answers of a minimum length are eligible