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, ...


24

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 ...


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: ...


6

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 ...


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 ...


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

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


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 ...


5

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 ...


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

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 ...


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

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

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 ...


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

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

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

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

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, ...


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

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 ...


3

As far as I've ever known, SSL certificates are not restricted to use on specific IP addresses or blocks of addresses. Most likely Comodo is asking for your region for some billing purpose (e.g. if you live in Europe they may have to do some EU-specific billing). In fact, I can see that by changing the region, they change the currency in which your price is ...


3

You need to include the NameVirtualHost xx.xx.144.72:443 directive.


3

Wildcard certs only go one level deep. You will need to get a wildcard that also has subject-alternate names for all www.<subdomain>.example.com sites. This will allow the redirection to happen. Any solution other than putting valid certs on the two-level-deep subdomains will not work, because the SSL handshake will always happen before any ...


3

Apache doesn't support SNI until version 2.2.12. Before this, Apache simply served the first certificate. After decrypting the request, it will still match the correct vhost. If you only have one IP address, you will have to upgrade Apache. (Even if you do have more than one IP address, Apache has come a long way since 2.0.59. You really should upgrade ...



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