Is it possible to change the certificate "Intended Purpose" for example if it has been ordered as "Client Authentication" to also include "Server Authentication" after the certificate was ordered or not? Most forums I looked at seem to indicate that the certificate has to be re-order. please note this certificate was ordered via a third party. Any feedback will be much appericated.
Most forums I looked at seem to indicate that the certificate has to be re-order
they are correct. The certificate is digitally signed by CA and any attempts to edit the certificate will invalidate the signature. You have to re-order the certificate from CA (third party, in your case).
Related
I did a scan of my domain using ssllabs.com, and this is what it says:
From what I can tell, one of my CAs is USERTrust RSA Certification Authority, and their certificate is expired, which SSLLabs flagged red, but it still says that there are no chain issues, and no browsers complain about talking to my domain.
I did the check after curl was complaining about an expired cert when talking to my domain, which may or may not be related.
What's going on here? How can an expired CA certificate not be a problem?
The expired certificate is actually not used for validation. It is unnecessarily send by your server, i.e. you could remove it from the certificate chain you send since modern system have a trusted CA builtin which effectively replaces this expired intermediate CA. For more details see for example USERTrust Intermediate Expiration in 2020. To cite:
This is an old intermediate certificate and modern operating systems have a new version available and won't be affected. ... Based on what we know, equipment released or receiving security updates after June 2010 will most likely not be affected. ...
Generating a CSR needs the server-name, organization, country etc. The server-name is used in SSL to make sure the server you are talking to is the server which was certified. Question is (1) what is the relevance of server-name if I use a certificate for code-signing?
Code signing certificates are different from SSL certificate only in flags. Rest is all the same. Now if I take a SSL certificate issued to foo.com and install it on bar.com then it wont work. What about code signing certificate? If a take a code signing certificate issued to foo.com and install it on bar.com and sign DLLs or JARs from there, then would there be any problem (2)?
I guess there should not be any. I do not have such a certificate so I cant test it, but by theory should there be any problem?
what is the relevance of server-name if I use a certificate for code-signing?
there are no dependencies. However, proper subject field will help to identify the original publisher.
then would there be any problem
no. There is no other subject name to compare. For code signing certificates, subject may be any, it must be just descriptive.
A certificate authority is supposed to verify a website is truly who they say they are, right. But certificate authorities sign there own certificates. So those certs are self signed. Is there a way I can find out if the self signed certificates they use on their website is reputable and trustable?
You have to trust the CA who issued the certificate. Otherwise, we encounter the classic chicken-egg problem where there is no concrete boundary for trust and certainty.
Once you trust the CA issuer, you can check whether the certificate you have was actually issued by the concerned CA by writing the following on a command line:
$ openssl verify -verbose -CAfile cacert.pem server.crt
Expected Output: server.crt: OK
If you get any other message, the certificate was not issued by that CA.
Visit https://kb.wisc.edu/middleware/page.php?id=4543 for more info
No, you just trust them! The most common way is to follow the herd... for example, extracting them from the browsers (http://curl.haxx.se/docs/caextract.html). We are always assuming the browsers are verifying it for us... as well as the operating systems...
Is there a way [you] can find out if the self signed certificates they use
on their website is reputable and trustable?
You can research the certificate authority yourself.
Some people may not trust a certificate authority, including Google. Google posted a list of authorities they did not trust back in May of 2016:
https://www.theregister.co.uk/2016/03/23/google_now_publishing_a_list_of_cas_it_doesnt_trust/
You either have to trust that the pre-installed certificates that came with your tools (web browser, etc) are trusted by the producers of those tools, or you can do some research and see if you really trust them yourself. It's basically like asking how you can trust anyone or anything. Can I trust you?
I trust the CA's that come installed with my browser because well, if I can't trust them then we all have a problem and that problem is bigger than me. I think it's good to ask questions like this and I wonder if anyone other than Google are questioning certificate authorities.
We have to send a SAML Response XML converted into a Base64 String to a vendor using a self-posting form.
I have setup the SAML and I have signed it with a certificate, but the certificate I used was the wrong one. The vendor asked for a certificate acquired from a CA (Certification Authority).
The problem is I do not know which certificate to choose from at the CA. I'm looking at the type of certificates I can buy from verisign. The two options is a SSL certificate or a Code Signing certificate.
Any thoughts on what certificate I need? And an explanation would be welcome :)
For your use, you want the SSL certificate.
There's a great explanation for the differences between the types in this other SO Q&A.
I'm a beginner in OpenSSL tools. I don't understand some concepts. Can you explain these concepts to me?
I want to understand concepts such as CA,Self-Signed Certificate or any concept for better understanding.
(Sorry if I am using the wrong terminology or grammar, I am learning english language.)
The purpose of certificates is to assert a piece of information in a way that you can verify. Public key certificates, more specifically X.509 certificates in this context, assert the binding between a public key, identifiers (the Subject Distinguished Name and/or Subject Alternative Names) and various other attributes. Altogether, these pieces of informations are signed so as to form the certificate.
X.509 certificates have both an issuer and a subject. The subject is the identifier representing who or what that certificate identifies (and who or what owns the private key matching the public key within this certificate). The issuer represents the identifier of the person or organisation that what used their private key to sign this certificate.
Certificate usage can be broadly split into two different categories: certificates that are used for a specific application or service (e.g. authenticating an SSL/TLS server), and certificates that are used to prove the validity of other certificates.
For the latter, certificates are used as building blocks of Public Key Infrastructures (PKIs). A Certification Authority (CA) is an institution that issues certificates: it signs the assertion that binds the public key in the certificate to the subject. When doing so, it puts its own name as the issuer name in the certificate it issues.
If you compare a certificate to a passport (which binds together your picture and your name), the CA would be your passport authority: those who actually certify that what the passport says is true, for others to be able to verify it.
Trusting a CA allows you to trust the certificates it has issued. You can build a chain of trust between a CA you trust and certificates issued by this CAs which you haven't seen before.
Along with this comes a "bootstrapping" problem: how do you trust the CAs themselves?
Self-signed certificates are certificates where the issuer and the subject are identical; they are signed with the private key matching the public key they contain. They are at the top of the chain of trust. They tend to be CA certificates (unless bespoke for a particular service, which you wouldn't be able to trust without external verification).
CA certificates are certificates that can be used for issuing/validating other certificates. (They can be intermediate CA certificates if they are in the middle of the chain between a root/self-signed CA certificate and a certificate you wish to verify.) The rules defining how certificates can be used to verify other certificates are defined in the PKIX specification (RFC 3280/5280).
Browsers and operating systems come with a pre-installed list of CA certificates that you trust by default. These are mostly commercial CAs which check the information about the service in the certificate, often for a fee. In counterpart, you can trust the content of the certificates they issue (most of the time, it's not a perfect system). There is a "leap of faith" involved here, since you need to trust the browser/OS to have included only reputable CA certificates.
If you use openssl s_client and you see a message like "self-signed certificate in the chain" or "unable to verify certificate", it doesn't necessarily mean that something is wrong, but openssl doesn't use a pre-defined list of trusted CA certificates by default. Most of its command have an options like -CAfile or CApath that allow you to specify which CA certificates you are willing to trust.
Self-signed certificates for a service are a specific case, whereby the service self-asserted its content. You generally have no way of verifying the authenticity of such a certificate, unless you have an external way of trusting it (for example, if you have installed it yourself on a machine and change check its content manually, or if someone you trust gave it to you).
(You may also be interested in this question about how an HTTPS server certificate is used.)
Generally the purpose of a certificate is to establish a trust chain: "I trust this 3rd party company, they trust you, therefore I can trust you." Self-signed certificate means you generated it yourself, and therefore I'm really not gaining trust in you. (These are great for testing, but not much else.) The other type is a trusted certificate, obtained by getting a reputable company to sell you one (like Verisign). It's a commodity market, so their prices are pretty consistent between companies. It does depend on the intended use and the scope of the certificate. (e.g. a certificate for signing an Android app is very different from a certificate used for validating https://www.example.com/.)
The "CA" or Certificate Authority is the company that issued the certificate. In the case of a trusted certificate, it's that company -- e.g. Verisign. In the case of a self-signed certificate, the CA is you -- you issued the certificate.
Self-signed certificates will cause some kind of "untrusted" alert in most browsers, asking you if you want to proceed and add an exception, etc. This does not mean the connection is any less secure though -- it is still over SSL.
Generally CA's charge a fee but there are some free ones around if you search.