Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
What is the main difference (may be pro/con list) between buying a custom SSL certificate and getting one from Free certificate provided by Let's Encrypt.
This is all about just having simple https in our Web Application
P.S I believe you understand what I am trying to do.
The main practical difference is to be trusted in all browsers and third party systems, for example Android, iOS or Windows.
Lets encrypt has taken this restriction into account and has proposed a solution that you can read on its website https://letsencrypt.org/certificates/
Our intermediate is signed by ISRG Root X1. However, since we are a very new certificate authority, ISRG Root X1 is not yet trusted in most browsers. In order to be broadly trusted right away, our intermediate is also cross-signed by another certificate authority, IdenTrust, whose root is already trusted in all major browsers. Specifically, IdenTrust has cross-signed our intermediate using their DST Root CA X3.
That is, in fact, their certificates are signed by a trusted 'usual' CA. So in practice there is no difference
Take a look at letsencrypt's own web certificate, it is signed by DST Root CA X3 (IdenTrust)
I have checked if CA is present in some keystore:
Chrome, IExplorer, Edge (using windows 10): OK
Mozilla Firefox: OK
Android (Nexus 5x -android 7): OK
Full list here: https://letsencrypt.org/docs/certificate-compatibility/
Related
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last month.
Improve this question
I'm having a reading of this documentation on certificates in Azure App Service, and having trouble understanding this sentence, regarding the meaning of merging intermediate certificates:
If your certificate authority gives you multiple certificates in the certificate chain, you have to merge the certificates following the same order.
What is the purpose of CA giving multiple certificates in the certificate chain, if ultimately you have to merge them? Why not giving only one?
On the other hand, someone already holding multiple certificiates, why would they want to merge them, and not making use of them for multiple purposes?
By default each certificate is untrusted. If untrusted certificate signs another certificate then both are untrusted.
But there are self signed certificates issued by root certification authorities that are trusted.
These are installed in each computer. In windows you can view them in certmgr.msc
Press the Windows key + R to bring up the Run command, type certmgr.msc and press Enter.
These are certificates that are trusted.
Consider situation when some trusted certificate from Root CA "A" (for example) signs another certificate "B" and then "B" certificate signs "C" certificate.
Then "C" - "B" - "A" are creating chain of trust.
"C" references "B" and "B" references "A"
"C" certificate is trusted only if "B" certificate is included.
It's not enough that "C" certificate is signed properly. "B" certificate must be included to prove it.
That's reason why you have to merge certificates.
("A" certificate is not necessary in merge because it is from Root CA and is already stored in each PC)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
If the SSL is all about encryption and public-private key, why we have multiple type of certificates(like regular and wildcard)?
Is there any third-party server in process of paid-certificates handshake?
The origin of the certificate does not matter for the TLS handshake itself. For the verification of the certificate it is only relevant if the issuing certificate agency is included in the applications or systems trust store. There are CA like Let's Encrypt which issue certificates for free and which are included in most systems trust store.
For the various types of certificates (wildcard etc) same can be said, i.e. it does not matter if this certificate was issued by a paid CA or not.
EV certificates are a bit different. These were historically considered special since the validation of the certificate owner was more tough and not everybody could get one. They were also more expensive due to this process. And only some CA would be able to issue such certificate and these CA where marked as such in the browsers But the relevance of these EV certificates is going down and some browsers already don't show them as special anymore.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
Due to a vulnerability in a WAF system we are required to rotate our SSL certificate on our website. we have to update the SSL certificate in several places.
My question, if I renew the SSL certificate from the CA and take time to deploy it on various servers. will this issue cause any outage on the site.
some of the places where I need to deploy:
WAF
Cloudfront
Nginx
As long as the old certificate is still valid (i.e. not expired and not revoked) it will continue to work so you can take some time to roll out the new certificate you've got. You can also run a mixed setup where some installations have the new certificate while others still have the old one.
While your specific use case is unknown it might be that due to the vulnerability the private key of the previous certificate was compromised which should (hopefully) lead to a quick revocation by the certificate. In this case you have to roll out the new certificates as fast as possible since due to the revocation clients might not accept the old certificate any longer.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have a WCF service hosted under IIS 6.0 running under Windows 2003 R2. The service is SSL secured with "Required client certificates" option.
When I browse the service from IE within win 2003 R2, I am able to see the WSDL.
When I try to browse from my development machine running IE on Win XP. I see 403.7 error like this.
The page requires a client certificate
......
......
HTTP Error 403.7 - Forbidden: SSL client certificate is required.
Internet Information Services (IIS)
I have spent 5 days on it tried everything possible like
Checking the client certificate on Client, private key, importing it again and again.
Checking its intended purpose (client Authentication) and EKU value.
Checking the CA is installed on both server and client in Trust Root Cert Authority Folder.
Running SSL Diag tool. Unfortunately it shows the message which i pasted above and not much detail.
It works when I try the option "Accept Client certificates" under IIS Directory security tab.
Is there something that I am missing or unaware of it?
Finally with the help of MSFT support, I have resolved it.
The reason was, on the webserver there were too many certificates in the Trusted Root Certificates Authority folder that it exceeds the recommended length. Hence i got this warning in eventlog.
When asking for client authentication, this server sends a list of
trusted certificate authorities to the client. The client uses this
list to choose a client certificate that is trusted by the server.
Currently, this server trusts so many certificate authorities that the
list has grown too long. This list has thus been truncated. The
administrator of this machine should review the certificate
authorities trusted for client authentication and remove those that
do not really need to be trusted.
I did delete some the the expired/unused certificates but still it wasn't sufficient. I couldn't delete more certificates due to fear of breaking the system because they were not expired.
We used method 3 to fix the problem which is discussed here
Though it had fixed my problem but only draw back of using this method is, client browser will present you the list of all client certificates present in the computer instead of choosing which one server wants based on the Trust Root CA.
This works for me because I have a WCF service and not a website.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
How come the prices on SLL certificates are so drastically varied? GoDaddy and Namecheap for example have them starting at $9 and $49 respectively. Then Verisign has them starting at $1500!
What's the difference? That's a huge price difference.
I have an application where each user account is on it's own subdomain, and so I need a certificate that covers them all.
Thoughts, suggestions?
The actual differences are:
Price
Support
Level of Certificate Validation
Who/what trusts the Root CA
Really, It all comes down to the Root CA (Certificate Authority).
Verisign's Root CA is trusted by pretty much every device and browser out there.
If you purchase a certificate from (say) GoDaddy, then it will probably be trusted by your major browsers and operating systems. However, if you need SSL certificates to work on a particular brand of set-top-box, or mobile device, then you need to find out what Root CA's they trust.
While the certificate from an untrusted Root CA will still be perfectly valid, the device (browser, gadget, whatever) has no way to verify that it's a legitimate certificate.
I believe the cost of an SSL cert generally comes down to things like encryption strength, issue time, update time, support, warranty, and things of that nature.
With regard to users on sub domains how about a wildcard ssl certificate from Comodo? Expensive but will cover your entire site in one hit.
http://www.instantssl.com/ssl-certificate-products/ssl/ssl-certificate-sgc-wildcard.html
Edit Found a comparison site http://www.whichssl.com/comparisons/index.html
there are diffrent types of levels of ssl, meaning more verified = more money in short...
It's all about the marketing. A Godaddy cert will get you just as far as a Verisign one (I know, I've had both).