Is there any CA that still issues SHA-1 certificates?
I need it for TR management to manage devices with base firmware that does not support sha256.
imho, Public CA's will no longer issues SHA-1 certificates; they are bounded by the strict guidance of the Certificate Authority/Browser Forum to no longer issue new server certificates with SHA1 signature algorithm.
7.1.3. Algorithm Object Identifiers
Effective 1 January 2016, CAs MUST NOT issue any new Subscriber
certificates or Subordinate CA certificates using the SHA‐1 hash
algorithm. CAs MAY continue to sign certificates to verify OCSP
responses using SHA1 until 1 January 2017. This Section 7.1.3 does not
apply to Root CA or CA cross certificates. CAs MAY continue to use
their existing SHA‐1 Root Certificates. SHA‐2 Subscriber certificates
SHOULD NOT chain up to a SHA‐1 Subordinate CA Certificate.
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.7.pdf
Related
When a TLS handshake takes place, the server sends in his ServerHello message, his digital certificate. This digital certificate is digitally signed by a intermediate CA named A and CA A also has a certificate which is signed by CA named root whose certificate is self signed, thus forming a certificate chain. The client then has to establish a trust, validating the server certificate. To perform that validation the client has to validate the entire chain correct?
Must the client have in a truststore all the certificates (A and Root) or the client will download them?
The client usually has only the root CA in the local trust store. The leaf certificate and the intermediate certificate leading to the root CA need to be provided by the server. The intermediate certificates are usually send in addition to the leaf certificate within the TLS handshake.
But it is a typical misconfiguration to only have the leaf certificate send by the server. In this case the certificate validation will fail unless the client has already knowledge of the intermediate certificates or can obtain these somehow. Since often the same intermediate certificates are used, some browsers like Firefox will cache the intermediate certificates they'll got when communicating with server A and fill these in when a broken server B is not sending the required intermediate certificates. Other browsers (like Google Chrome) will try to download the missing intermediate certificates from the internet. Most simpler clients (i.e. apps written in Python, Java ... or curl) will instead just fail with a certificate validation error.
A
/ \
B C
| |
D E
when E (or C) is verifying D's certificate he needs to trust B also.
is there a way to avoid having to explicitly add B's cert to E's CA store?
using openssl, is there the way to automate the retrieval of B's cert either from the client or another source (maybe a field like issuerDistributionPoint in D's certificate)?
is there a way to avoid having to explicitly add B's cert to E's CA store?
The common way is to send all intermediate certificates along with the leaf certificate inside the TLS handshake. For instance if you connect to google.com you get the following certificate chain provided by the server within the TLS handshake:
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
Using the intermediate certificates (1,2) the client then can build the trust chain from the leaf certificate (0) up to the locally stored trusted CA (/C=US/O=Equifax/OU=Equifax Secure Certificate Authority in this case).
Of course you might also add the intermediate certificates as trusted in the clients. But since there are a lot more which also change more often than the trusted root certificates you would need a bit more memory but you would also update your clients regularly with the new intermediate certificates.
using openssl, is there the way to automate the retrieval of B's cert either from the client or another source (maybe a field like issuerDistributionPoint in D's certificate)?
openssl does not provide specific tools to deal with this. The desktop browser Google Chrome will actually try to download missing intermediate certificates from the internet, probably based on the information in the Authority Information Access part of the certificate. But I'm not aware of other browsers (apart from other Chromium derivates like Opera) doing this.
Here is my situation:
I have a client application that I'm going to distribute - we'll call it MyClient.
MyClient does some SSL communication with one of our servers.
MyClient has the root CA embedded in it, so it can do proper verification of the server certificate.
Now, suppose some years go by, the root CA expires, and is renewed.
Does that mean I need to patch MyClient in the wild?
In other words, will a change to the validity dates on the certificate cause it to no longer match the baked-in root CA in MyClient?
Addendum: Suppose I write my client to not validate the date of the cert (but everything else). Then, when the root CA expires and is re-issued, do I still need to patch? Will other parts that play into the validation change, other than the date?
If your client is ensuring an SSL server certificate is issued by a particular root CA and that root CA is included in the client then yes, you will need to patch your client to replace the root CA certificate.
There are few good ways of doing this. What tends to happen is that root CA certificates are very long lived and use shorter lived intermediate CAs to issue SSL certificates but it sounds like this is not the case here.
Looking on the bright side, I do not know what algorithms were used with the old root CA certificate but, hopefully, The new root CA certificate will hopefully use a larger key (2048-bit RSA rather than 1024-bit or 512-bit) and a better hashing algorithm (SHA1 or better rather than MD5) so it may be a good opportunity to increase security.
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.
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 2 years ago.
Improve this question
I'm not clear on the difference between a CA key and a certificate. Isn't a CA key simply a certificate? Let me try and clarify with an example.
I have a client and a server. I'm only trying to validate my connection to my server and not trying to establish trust to others so I don't care about signing with a real CA.
Option 1: Generate a self-signed CA (ssCA) and use that to sign a certificate (C). I then install ssCA into the root keystore on my client and setup my server to use certificate C.
Option 2: Generate a self-signed certificate (SSC). Install SSC into the root keystore on my client. Setup my server to use certificate SSC.
The second option seems like a much simpler process. Should that still work?
First, about the distinction between key and certificate (regarding "CA key"), there are 3 pieces used when talking about public-key certificates (typically X.509): the public key, the private key and the certificate.
The public key and the private key form a pair. You can sign and decrypt with the private key, you can verify (a signature) and encrypt with the public key. The public key is intended to be distributed, whereas the private key is meant to be kept private.
A public-key certificate is the combination between a public key and various pieces of information (mostly regarding the identity of the owner of the key pair, whoever controls the private key), this combination being signed using the private key of the issuer of the certificate.
An X.509 certificate has a subject distinguished name and an issuer distinguished name. The issuer name is the subject name of the certificate of the entity issuing the certificate. Self-signed certificates are a special case where the issuer and the subject are the same.
By signing the content of a certificate (i.e. issuing the certificate), the issuer asserts its content, in particular, the binding between the key, the identity (the subject) and the various attributes (which may indicate intent or scope of usage for the certificate).
On top of this, the PKIX specification defines an extension (part of a given certificate) which indicates whether a certificate may be used as a CA certificate, that is, whether it can be used as an issuer for another certificate.
From this, you build a chain of certificates between the end-entity certificate (which is the one you want to verify, for a user or a server) and a CA certificate you trust. There may be intermediate CA certificates (issued by other CA certificates) between the end-entity certificate of your service and the CA certificate you trust. You don't strictly need a root CA at the top (a self-signed CA certificate), but it's often the case (you may choose to trust an intermediate CA certificate directly if you wish).
For your use case, if you generate a self-signed certificate for a specific service, whether it has the CA flag (basic constraints extension) doesn't really matter. You would need it to be a CA certificate to be able to issue other certificates (if you want to build your own PKI). If the certificate you generate for this service is a CA certificate, it shouldn't do any harm. What matters more is the way you can configure your client to trust that certificate for this particular server (browsers should let you make an explicit exception quite easily for example). If the configuration mechanism follows a PKI model (without using specific exceptions), since there won't be a need to build a chain (with just one certificate), you should be able to import the certificate directly as part of the trust anchors of your client, whether it's a CA certificate or not (but this may depend on the configuration mechanism of the client).
Both options are valid, option 2 is simpler.
Option 1 (setting up your own CA) is preferable when you need multiple certificates. In a company you might set up your own CA and install that CA's certificate in the root keystore of all clients. Those clients will then accept all certificates signed by your CA.
Option 2 (self-signing a certificate without a CA) is easier. If you just need a single certificate, then this is sufficient. Install it in the keystores of your clients and you are done. But when you need a second certificate, you need to install that again on all clients.
Here is a link with further information: Creating Certificate Authorities and self-signed SSL certificates
You can openssl x509 -noout -text -in $YOUR_CERT to see the differences between files contents:
In your self-signed CA, you can see：
X509v3 extensions:
X509v3 Basic Constraints:
CA:TRUE, pathlen:0
And in your self-signed certificate, it's:
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
If you need more certificates (C), you need to create a self-signed CA (ssCA).
If you need a single certificate, you can just create a self-signed certificate (SSC).
To trust the single certificate (SSC), you need to install SSC into the root keystore on your client.
To trust many certificates at once, you need to create a self-signed CA (ssCA), then install ssCA into the root keystore on your client.
You must always have a root CA, the CA has a key that can be used to sign a lower level certificate and a root certificate that can be embedded in the accepted root certificates on the client and is used to verify the lower certificates to check they are valid. Self signed just means you are your own CA. Whenever creating a self signed certificate you create a ca, then sign a site cert with that CA.