The signature of the root CA certificates do not matter at all, since there is no need to verify them. They are all self-signed.
If you trust a root CA certificate, there’s no need to verify its signature. If you don’t trust it, its signature is worthless for you.
Edit: there are some very relevant comments below. I don’t feel comfortable copying or ...
I believe that with respect to deciding where to purchase a wildcard SSL certificate, the only factors that matter are the first year's cost of an SSL certificate, and the pleasantness of the seller's website (i.e. user experience) for the purchase and setup of the certificate.
I am aware of the following:
Claims about warranties (e.g. $10K, $1.25M) are ...
At the end of the day, a root certificate is self-signed. It is never signed by another entity except itself. The root certificate gets its trust through out-of-band processes like submitting it to a browsers list of trusted publishers, or getting it accepted by Microsoft for insertion into the default list of Windows trusted publishers.
These certificates (...
Yes, it is possible. In the case of Windows, there is a feature called Cross-Certification or Qualified Subordination.
The idea is that you sign third party's issuing CA certificate in your environment. As the result remote SSL certificate is chained to your own root CA certificate. In order to protect yourself from possible rogue certificates, you ...
According to the SSL FAQ:
the validity (and thus level of trust) of a given certificate is determined by the corresponding validity of the higher-level certificate that signed it.
So while it is technically possible to make a certificate which lasts longer than its issuer, it makes no sense, as the chain becomes broken the moment an intermediate (or the ...
The recommended way of doing that on RHEL 6+ systems is to use update-ca-trust tool, which is now installed by default.
# cat /etc/pki/ca-trust/source/README
This directory /etc/pki/ca-trust/source/ contains CA certificates and
trust settings in the PEM file format. The trust settings found here will be
interpreted with a high priority - higher than the ...
If the server sends you a TLS alert unknown ca like in this case then the server does not accept the client certificate you have send (-E my.pem). One reason for this might be that you have used the wrong certificate. Another reason might be that you've used the correct certificate but failed to add the necessary chain certificates.
verify error:num=20:unable to get local issuer certificate
This error by OpenSSL means the program was unable to verify the issuer of the certificate or the topmost certificate of a provided chain. This can happen in some cases, for example:
The certificate chain for the certificate wasn't provided by the other side or it doesn't have one (it is self-...
The basic infrastructure, that would make this possible, exists and is called DNS-Based Authentication of Named Entities (DANE) and specified in RFC6698. It works by means of a TLSA resource record, that specifies the certificate or its public key of the end entity or one of its CAs in the chain (There are actually four different types, see the RFC for ...
No, that won't work.
In order to sign certificates you need your own certificate authority certificate. The certificates you purchase are signed by a certificate authority, but specifically marked as not being a certificate authority certificate.
Check the "Certificate Basic Constraints" in your certificate, and you will see that it "Is not a Certification ...
This means that iOS does not trust the publisher of your certificate, but as you've mentioned, there is a GoDaddy root certification in the iPhone.
What this probably means is that your RADIUS server is not sending its intermediate certificates. The Windows and Android devices probably already have this intermediate certificate trusted, but your iOS devices ...
I've noticed that CA extensions could be missing in the renewed certificate of the original CA key.
This worked more appropriately for me (it creates a ./renewedselfsignedca.conf where v3 CA extensions are defined, and ca.key and ca.crt are assumed to be the original CA key and certificate):
openssl x509 -x509toreq -in ca.crt -signkey ca.key -out ...
ca-bundle.trust.crt holds certs with "extended validation".
The difference between "normal" certs and certs with EV is that you EV certs need something like a personal or company validation by i.e. validating the identity of a person by his/her passport.
This means that if you want to get an EV cert you'll have to identify yourself to the cert issuer by i....
There is significant difference between Standalone and Enterprise CAs and each have its usage scenario.
This type of CAs offer the following features:
tight integration with Active Directory
When you install Enterprise CA in AD forest, it is automatically published to AD and each AD forest memeber can immediately communicate with CA to ...
But what happens if my CA itself expires (root CA an thus issuing CAs)?
Literally, nothing. Let's explain it a bit in more details.
If the signature is not timestamped, the signature is valid as long as:
data is not tampered
signing certificate is time valid
neither certificate in the chain is revoked
root certificate is trusted
Once signing certificate ...
The signature of the certificate depends only on the public key in the issuer certificate and not on the expiration of the issuers certificate or other parameters. The path validation though depends on all certificates in the trust chain not being expired.
If the client has only the server certificate and an expired issuer certificate then the path ...
There's no use to including it. If the client browser or library has it as a trusted certificate then it obviously doesn't need another copy, if it doesn't have it then including it isn't going to make it trust it.
I have no idea why Namecheap would include it in their instructions. Abundance of caution? It's not an error or spec compliance violation to ...
I think using PowerShell might be the way to go.
$srcStoreScope = "CurrentUser"
$srcStoreName = "CA"
$srcStore = New-Object System.Security.Cryptography.X509Certificates.X509Store $srcStoreName, $srcStoreScope
$cert = $srcStore.certificates -match "sometext"
The expiry was set in 2037 to avoid the possibility of running into the Unix year 2038 date problem. Basically in early 2038 Unix dates will no longer fit in a signed 32bit integer so using a date just before then avoids triggering any code not yet updated to fix the problem.
Root certificates take all chained certificates with them when they expire so from ...
Both, Qualys SSL test and Comodo are correct.
Comodo is correct from the server-side code perspective. Nginx should trust certificates it uses.
On the other hand, Qualys SSL test is correct from network protocol perspective. During SSL negotiation, server must send its own SSL certificate and all intermediate CA certificates except root certificate. A ...
You've fallen into a SNI hole.
SNI is server name indication. This allows you have multiple different hostnames living on the same shared IP. And if you don't actually indicate a servername to a SNI enabled server, then you get back the default certificate. (This is the "SNI hole" part.)
And OpenSSL will not supply a servername to the TLS server ...
It might happen because curl can't access valid CA certs bundle. Maybe you just didn't install those, so try this:
apt-get install ca-certificates
If it doesn't help - check CURL_CA_BUNDLE, make sure curl doesn't look for bundle in a wrong place.
You need to be joined to a domain to be an Enterprise CA, but you do not need to be domain joined in order to be a standalone CA. An Enterprise CA adds features that come along with being integrated with Active Directory, but the downside is that you cannot take it offline as you would do with a high-security root CA.
Yes it is possible to install AD CS on ...
Unless that PEM file actually contains the CA certificate for the client certificates you wish to grant access, this is incorrect; to provide apache with a certificate chain, use SSLCertificateChainFile instead.
Apache must have the actual certificate and any intermediate certificates used to sign/...
Another point to consider is the reissue of certificates.
I didn't really understand what this meant until the heartbleed bug came along. I'd assumed that meant they'd give you a second copy of your original certificate, and I wondered how disorganized one had to be to need that service. But it transpires that it doesn't mean that: at least some vendors ...
If you want to create multiple certificates with the same subject, you can change your configuration like that:
You can change in the CA section (probably [CA_default]) in your openssl.cnf the setting
unique_subject = no
But this setting is also saved in file index.txt.attr, you have to change this, too. Otherwise it will not work.
If a CA had a root cert that had a suitably long expiration, they could issue certs for an equivalently long time. Certs issued by a CA will not be valid longer than the root cert even if the child cert has a longer expiration.
It seems that this is due to the oddball GPO that my company uses.
As outlined here the GPO setting Computer Configuration\Administrative Templates\System\Internet Communication Management\Turn off Automatic Root Certificates Update was Enabled, meaning that the OS wouldn't pull root CAs from Microsoft. Setting this to Disabled fixed the issue.