We have to update our SSL certificate for an other year with a new COMODORS certificate.
We've had a old certificate (GeoTrust) with *.domain.ch which is correct from the naming aspect but expired from the date.
Now we've falsely made one with *domain.ch without the first dot. This should be a wildchart certificate for our domain.ch.
Will this work or can this be the problem for server not starting after this SSL certificate update?
No it will not work. This certificate will match against wwwdomain.ch but not www.domain.ch. But, no public CA should issue such a certificate in the first place since you could this way impersonate foo-domain.ch etc, i.e. domains which don't belong to you.
If this certificate is in a pipeline to get issue then it won't get issued. If got issued erroneously then you have to re-issue the certificate from the vendor or the CA as the *domain.ch won't work.
can this be the problem for server not starting after this SSL certificate update?
Server won't start as there is a mismatch in the domain name
Related
i installed the Ssl certificate on my server but i have this error
This server could not prove that it is spdns.ir; its security certificate is from vmi90749. This may be caused by a misconfiguration or an attacker intercepting your connection.
anyone can explain me what is the problem and how i should fix it ?
tnx
The error is quite self-descriptive. The certificate is issued to vmi90749 name, while you are trying to access a spdns.ir name. There is nothing common between them. You need to install a certificate that is issued to spdns.ir name and make sure it is issued by a trusted authority. Preferrably from a globally trusted CA vendor (there are CAs that issue certificates for free).
As aside note: when requesting new certificate for spdns.ir name, make sure that the name is added to Subject Alternative Names certificate extension. Google Chrome deprecated Subject field.
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!
I followed the instructions to the letter here -- https://devcenter.heroku.com/articles/ssl-certificate --, and they were helpful, especially since DNSimple is my registrar of choice. I got everything up and running as far as I know, purchased the certs (via DNSimple and RapidSSL), combined the crt and the CA bundle, and sent them up via the heroku client:
$ heroku ssl
www.website.com has a SSL certificate registered to /serialNumber=…
website.com has a SSL certificate registered to /serialNumber=…
But when I go to my apps (I even restarted them) they are still using the certs for *.herokuapp.com. Is there anything I've missed? Why would things be coming up as *.herokuapp.com?
From the top, here are the pieces provided to me from the related parties.
From DNSimple (on the cert details page) : Private Key
From DNSimple (on the cert details page) : Certificate
From RapidSSL's CA Download page (linked from DNSimple) : CA bundle "pem"
From email sent by RapidSSL / Geotrust : Web Server CERTIFICATE
From email sent by RapidSSL / Geotrust : INTERMEDIATE CA
I imagine that the "private key" is what I need in the second part of the heroku ssl:add dance: heroku ssl:add site.pem private.key
But it seems that I'm doing something wrong when I'm putting together the "pem" file for the first file I'm sending with heroku ssl:add. Of the pieces above - what needs to be combined in order for this to work?
I know this question is old, but I just hit the same problem and found the answer, at least in my case.
I had my DNS pointing to my-app.herokapp.com but the SSL endpoint is different. You can find the SSL endpoint like this:
$ heroku certs
Endpoint Common Name(s) Expires Trusted
------------------------ ---------------------------- -------------------- -------
osaka-5565.herokussl.com www.example.com, example.com 2014-05-18 09:32 UTC True
Your endpoint will be different from that. Once you change your CNAME and/or ALIAS records to point to the SSL endpoint, you'll get your own certificate instead of the herokuapp wildcard.
Make sure you're not viewing the naked domain name, https://yourwebsite.com is not supported with SSL on Heroku, whereas https://www.yourwebsite.com is.
If this ends up being the issue you'll have to make sure the naked domain name redirects to a subdomain like www.
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.