I have godaddy ssl certificate for domain.There wasn't any problems with my SSL certificate and visiting my domain(Haven't receive any errors), but couple times(two weeks ago) when I visited site from other(mobile, tablet and desktop) devices(different internet) I received SSL warning. I tested my domain on sslshopper.com and in this system shows that everything is okay with our SSL(Expiry date in 200 days). But I tested my SSL in ssllabs.com and SSL got only C grade. Maybe you have any idea why such stuff happening? Is it possible that if we would change SSL to other one, there wouldn't be such error at all? Maybe you experienced something similar and you can help out. Because warning appears only sometimes and in different devices, but other than that everything is perfect
When some client devices show problems, and others don't, it must likely because some client's don't contain the necessary Intermediate or Root Certificate Authorities to establish a chain of trust.
This is not the fault of the client device.
Rather, it is up to the server-side (ie. the side sending its certificate) to supply enough of the chain (ie. its certificate, and its CA certificate(s)) so that the client can use those to fill in the steps in the chain until it gets to a certificate that is signed by another certificate that it has in its trusted CA keystore.
You're very likely only supplying the server certificate.
Also possible, but generally less likely, is that the certificates are being offered by the server in the incorrect order.
To help you further, we would need to have some details as to what software is implementing the SSL server end-point.
Cheers,
Cameron
Related
I have bought a domain and certificate from Azure. The certificate is given by Go Daddy as azure partner and it is signed with the intermediate certificate from Go daddy hence it always needs chaining of certificates till Root CA.
Our website is used as a REST interface for our customers and hence clients use Java SDK or plain scripts. In our case precisely with zulu jdk image(11u5-zulu-alpine) from microsoft and even I tried with ubuntu 16.04 LTS and get the same error.
if we try to even curl to our site with proper certificates we get error as below and its because of the intermediate CA is missing!
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
With java SDK we get as javax.net.ssl.SSLHandshakeException
I have 3 questions.
Do we need to bundle the intermediate and root certificate with our domain certificate and deploy it.( the certificate is in pfx format)
Is it a good practice to tell our clients to install the bundle certificates ( root and intermediate) in order to get this working.
Does GoDaddy needs to update the bundle certificate in the packing repositories of Ubuntu ,alpine Or is my understanding wrong
And lastly I have a fair idea of how certificates work w.r.t client and server but with the intermediate CA in picture I am unable to understand exactly where the intermediate CA should be put in. I read few posts on the SO but its still unclear. Please bear with me and if some one can explain me the approach how it works in general and what could be the good practice.
Do we need to bundle the intermediate and root certificate with our domain certificate and deploy it.( the certificate is in pfx format)
You should definitely configure the server to send all required intermediate certs; this is required by the TLS standards. (Although if you don't, clients have the option to try to obtain them by other means, like a cache or repository or AIA, and sometimes they do.) Whether the server sends the root is optional; the standards actually state this in reverse, by saying the server MAY omit the root, where the all-caps 'MAY' invokes the meaning defined in RFC 2119. E.g. for TLS1.2 in RFC5246 7.4.2:
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case.
How you do this depends on what web-server software you are using, which you didn't identify. Although from the fact you specify a Java version, I can speculate it might be Tomcat, or something based on Tomcat like Jboss/Wildfly. Even then, Tomcat's SSL/TLS configuration varies substantially depending on the version and which type of connector 'stack' you use (the pure-Java JSSE, or Tomcat Native, aka APR Apache Portable Runtime, which is actually OpenSSL). However, a 'pfx' (PKCS12) file can definitely contain both a privatekey and the matching (EE) certificate PLUS the chain cert(s) it needs, and is a convenient way to deal with the whole kaboodle at once.
For a cert obtained directly from GoDaddy, they provide instructions linked from https://www.godaddy.com/help/install-ssl-certificates-16623 for many common servers. I don't know if for Azure they use any different chaining that would alter these instructions.
If your server is publicly accessible, at port 443, https://www.ssllabs.com/ssltest will check if it is correctly handling the chain certs, as well as many other things. There are other tools as well but I am not familiar with them; for non-public servers I usually just look manually.
Is it a good practice to tell our clients to install the bundle certificates ( root and intermediate) in order to get this working.
Clients should not install intermediate cert(s) because as above the server should send them. The GoDaddy roots have been accepted in most official truststores for several years now, so most clients using default settings should not need to add them. However, some might; in particular Ubuntu 16.04 might be old enough that it doesn't have GoDaddy preinstalled. And any client(s) that wishes to use a customized truststore, and/or a pin, must ensure that it is set to include/allow your cert's trust chain.
Does GoDaddy needs to update the bundle certificate in the packing repositories of Ubuntu ,alpine Or is my understanding wrong
GoDaddy has supplied its roots to (AFAIK all) the major truststore programs, as above. IINM Ubuntu uses the Mozilla/NSS list, which definitely includes GoDaddy today, but as above I can't be sure about 16.04. I don't know for alpine. CAs do not request truststore programs to include intermediates (although a program or user may be able to add selected intermediate(s) as trusted, depending on the software used).
I'm not quite sure if this question applies to this forum but if it does maybe someone knows if it is possible using Open SSL to create a SSL sertificate that browsers wouldn't throw warning messadges that our created SSL sertificate is untrusted?
Technically it is possible if you have CA's private key to sign the newly created certificate. As you probably don't have a key, the answer is probably no. Just go ahead and purchase a certificate from one of CAs. If you do minimal research, you will find that some CAs offer very affordable prices.
This is probably better handled on server fault, but I will tell you that NO you cannot do this. The reason browsers don't like your certificate is that you are not a recognized certificate authority. As such, a browser will always warn about your certificate being untrustworthy, since the browser does not know who you are, or why anyone should trust you.
EDIT: As Alex K points out, you can install your certificate on machines you know will access your site, which works reasonably well for scenarios where the site will only be accessed by a limited number of known users/machines. My point still stands regarding wider distribution. Thanks, Alex.
For some of my site visitors, the SSL certificate is failing. Whatever tests I do on various browsers for me the SSL certificate is valid.
I can't think of how to test this on client side, and to identify the problem.
How would you do this?
One client gets: fatal certificate unknown
While RouMao's answer is mostly correct, he has missed what is (IME) the most common problem with SSL certificates - the certificate you are using requires an interim certificate from the CA which you have not included in your certificate chain. Most CAs provide an online tool for analysing the certificate - try the one located here.
Also, is there any correlation with which browser being used? Notably, Chrome does not handle SSL v2 by default
Most of the failing of SSL certificates were caused by visitors themselves. Somehow could not tests or verified by server implementation.
Here are some obvious examples:
Your cert is validated since April 1st 2012, but the client's local machine time is set to 2010 -- one year later than current time. In this case, the visitor should encounter problem all the times, until his machine time is later than April 1st 2012.
visitor is behind a restricted firewall. The firewall could terminate the SSL/TLS connection and re-crypt the link with a pseudo/self-sign certificate. Indeed this could be considered as a man-in-middle attach.
The Trusted Root Certification was removed by client himself
it is very hard to fix all these problem. Sometimes, you need to create a client side native application to detect or fix all the possible problems, and require client browser to execute the application each time before it enter the HTTPS mode.
P.S. most of the e-bank application do like this.
Here's a possible scenario.
Let's say I have a website "https://www.mywebsite.com" and there is a valid SSL certificate purchased for this domain.
I want to "mimick" this website on my LOCAL machine for a testing purpose.
So let's say I set up a locally-configured "https://www.mywebsite.com" (which is in essence https://localhost/mywebsite or something similar).
Would I be able to re-use the SSL certificate on my local testing website?
You can re-use your SSL certificate if you configure your DNS so that your test machine is the same domain name as server, which is probably a bad idea.
You can also re-use it on your test machine if you don't mind clicking the box "accept this whacked out ssl cert"... So I suppose that the answer is technically yes, although I wouldn't personally do it.
It depends what you are trying to test and why you need a certificate for testing.
If you use the certificate, it will correctly encrypt connections using SSL, but any client will get a certificate mis-match error. If you use a self-signed certificate instead, most clients will give you a warning about that, so it might be just as annoying or not.
If you are testing, for instance, a deployment script to make sure everything gets installed in the right place, it will work. If you are testing to make sure your code correctly redirects a non-secure connection to a secure one, it will work.
If you want to test the your website for functionality, usability, bugs, etc. then your testers will likely complain about the certificate warnings or errors, and you're probably better off doing something else.
I am not sure since the SSL certificate is bound by the domain name that was registered with the certificate. But you may be able to dupe the certificate by editing your hosts file to change localhost 127.0.0.1 to be mysite.com 127.0.0.1, ...in theory at least...if not this is a question for serverfault.com.
Hope this helps,
Best regards,
Tom.
You can't use it since the SSL cert is tied to the domain www.mywebsite.com unless you do a bit of trickery.
You can put an entry in your hosts file saying that domain is at 127.0.0.1, but that's not ideal as you could no longer reach the website.
If you just need a valid cert to test with, then a better alternative is to self-sign using the IIS Resource Kit.
I'm no expert on DNS, but this would introduce a pretty major vulnerability.
Basically if this was allowed, DNS poisoning could be used defeat the whole purpose of third party trust.
Think about it:
I infect your computer so that when you go to www.amazon.com it resolves www.amazon.com to a different domain. That domain uses amazon's ssl cert to fool you into thinking it's legit, so you send me your credit card information.
So, the answer to your question is, no you can't do this. You will still get errors, My guess is that somewhere on the verfication chain, it compares the domain that initiated the request with what its internal dns resolves the domain, to verify there is a match.
As others have said, you can test SSL with a Self Signed Cert, you just have to instruct your testers to import the cert, or go through the trouble of building your own trusted CA, and have testers add that CA as a trusted CA.
There is no point in stealing another sites SSL Cert.
Of course you could use the vulnerability in MD5 to create your own valid SSL cert.
http://www.digicert.com/news/2009-01-05-md5-ssl.htm
I'm trying to upload a file with a client application using BITS (Microsoft's Background Intelligent Transfer Service) via HTTPS. The development server I'm uploading to/testing with does not have a properly signed certificate for SSL (it's self-signed). This means that the transfer always errors out, as BITS recognizes that the certificate is self-signed and refuses to complete the job.
Is there any way to programmatically tell BITS ignore the certificate authority and complete the upload? I know there are ways to do this with the HttpWebRequest class in C#, but I don't know how to do this with BITS specifically.
Thanks!
This really racked my brain for quite some time. I finally figured out you need to enter the number in decimal form. (not like it shows in technet as 0x0001)
C:>bitsadmin /SetSecurityFlags myDownloadJob 8
The 8 will make the "Ignore invalid certificate authority in server certificate :true"
30 will make all of the Ignores true.
I think BITS is throwing an exception not because it recognises the cert as being self-signed but rather that it recognises that the cert is not trusted by the client PC. You could try installing the cert in the Trusted Store on your client - I believe BITS will then work over HTTPS.
Use /SETSECURITYFLAGS.
Source: http://www.howtogeek.com/wiki/Bitsadmin