Hot answers tagged

24

Yes, the number of compromised certificates are much larger with Root Certificate compromise. But it's not just the number certificates. Getting a new root certificates deployed due to compromised root is massively more difficult than replacing the certificates whose intermediates are compromised. For starters, replacing Root Certificate of a public CA, ...


13

Is that correct? Is there another benefit? An offline Root CA sacrifices convenience to gain security. But, anyway, CA must issue new Intermediate CA certificates and revoke the old ones... so the only benefit that I can find is that CA issue different Intermediate certificate for different purposes. Yes, in case of a compromised Intermediate, ...


8

When speaking about a trustworthy "Certificate Authority", we refer to the organization/entity issuing the certificates, and not the tool used to generate them. It refers to the entity in the "Issuer/Issued by" field of your certificate (e.g. DigiCert for this website). Thus, if you issued your own certificates using the same tools as DigiCert, say OpenSSL, ...


6

.. to only work with certain protocols? .. to only work with certain ciphers? Certificates are mostly protocol independent. But there is a slight correlation between certificate and cipher: one part of the cipher specifies the authentication algorithm and the possible algorithms depend on the kind of certificate. This means that you cannot use a RSA ...


6

Although Let's Encrypt issues domain-validated certificates and these guarantee only that a certificate was requested by an entity owning the domain, it does have policies in place to prevent imposters in certain cases. According to the stipulation "3.2.4.3 Verification against High Risk Certificate Requests" in "ISRG Certification Practice Statement" (v1.4,...


5

You cannot use your SSL certificate purchased from Let's Encrypt to sign other certificates. In order to do this, your certificate must be CA certificate. This is done by setting isCA=true in the BasicConstraints certificate extension. In addition, KeyUsages extension should include a keyCertSign bit enabled. Your SSL certificate doesn't have such setting ...


5

Subject identification in SSL/TLS server certificate is DNS name(s) usually and/or IP address(es) rarely, which are matched against the requested URL. Neither of these determines location. EV certificates must contain some physical location information verified by the CA, and other certs may, which the browser cannot further check; some browsers display some ...


5

Your trust store should contain the certificates you trust. If you trust only a single intermediate CA, and not its root, you should include the intermediate CA's certificate and not the root's. Once a chain of trust can be built to a certificate in your trust store, it doesn't matter if that certificate was issued by another CA or not.


4

So the "universe" of compromised certificates is smaller that if Root CA would have signed all of the certificates. Sure, you could put it that way. But until the intermediate CA has it's certificate revoked (and even after that, it could still be problematic), it could continue to create bad certificates that users will trust. Because revocation isn't ...


4

What you are looking for is to modify the certificate in a way that it contains the ability to be a CA, i.e. set the CA flag to true. Fortunately you cannot simply modify a certificate, because any kind of modification invalidates the signature and thus nobody will trust this certificate anymore. This is essential because otherwise everybody could just ...


4

In the context of ssl/tls a CAs main job is to assure the client that the server the client is connected to is the server the client intended to connect to. In some cases it may also be used to verify other things. Understanding this and understanding your clients is key to understanding when you should create your own CA. You need to ask yourselves some ...


4

HTTPS (or any TLS clients really) need to know the certificate revokation status before being able to trust that TLS connection. If the HTTPS connection used to fetch the CRL itself can't be trusted, then what is the point? Not to mention, your original HTTPS connection triggers a CRL lookup, which in turn triggers another HTTPS connection for the CRL server,...


4

Does the term "certificate authority" refer to the organization issuing certificates (symantec, comodo, let's encrypt, ...) Technically, yes. or to the device and software that issues certificates from CSRs or both? In practice, yes. A Certification Authority (CA) is defined as follows by RFC 5280: Following is a simplified view of the ...


4

I was wondering whether a CA has different private keys to sign certificates with? A CA will usually have a number of Intermediate Keys for use in signing customers' certificates. These Intermediate Keys are in turn signed by the CA's Root Key, which should be stored "offline" and only used rarely to sign those Intermediate Keys. The matching Root ...


4

["Facebook" here is just "an example of someone that wants a certificate." There is no inherent special Facebookness about this situation.] Who generated that public key that I can see in facebook certificate? Is it generated by Facebook or that intermediary CA? Facebook generates the "keypair" consisting of a public key and a private key. ...


3

"Complexity is the enemy of security" I would always look to use the least amount of certs possible for a number of reasons, mostly due to the ease of administration. It's my understanding that letsencrypt is not currently allowing wild card certificates (these certificates essentially allow you to secure all subdomains of a domain where the traditional ...


3

I was wondering whether a CA has different private keys to sign certificates with? In general, no. There is one key pair - and thus private key - per certificate. Certificates can be rolled over to use a new key pair of course. Furthermore, in general, a CA manages multiple certificates for different purposes. The CA may also have different certificates ...


3

You can create your own CA first and then supply the CA certificate to the SQL server (your OEM version). Any future certificate that you (as the CA) generate for the customer will then be trusted by the SQL server.


2

The sample code you link to does not do any kind of verification. It fails to verify the certificate chain because it does not use SSL_CTX_set_verify to enable verification (and the default is off). This way it accepts any certificate. It also fails to verify the hostname against the certificate. Even if chain validation would be done this would mean that ...


2

It depends on a multiple factors, certificate management strategy, policies and so on. For general purpose web applications I would go with a single certificate per machine if they use different names. You can run separate certificates on per-service basis, but this will increase administrative efforts in certificate management. If you go with single ...


1

(1) Does the verification of the chain end there or does it continue on until we get to D? it depends on a certificate chaining engine (CCE) implementation. Different platforms have different implementations which may not support all recommended/mandatory validation logic described in RFC5280. Certificate trust requires an end of chain point which is ...


1

The JDK is offered over HTTP because they also offer a hash for you to confirm over secure channels. Since the hash is over a secure channel, if that hash can't be confirmed you shouldn't use the download. The fact that the part of truth(the hash you check against) is delivered securely means they can offer it over HTTP because you will be able to securely ...


1

AFAIK, some of them are in countries, where single entity (gov) can covertly do whatever it wants on their machines. Yes, pretty many countries are like that today. Sadly, concerning governments, the CA system is not (and never was) secure. CAs are still good for preventing some people and organisations from attacking, just not all.


1

It is an arbitrary, administrative decision for the creator of CA what client certificates they want to enable to be signed by the CA. The policy_match in the following configuration line: policy = policy_match is a chosen name that corresponds to a particular section in the configuration file. That section defines in details each of the [ ...


1

You can include them in the CSR if you want, but the R stands for request, and no CA will issue you a certificate if your CSR does not comply with its policies. In fact, most CAs ignore everything in your CSR except for the key material.


1

It would help if you think of the certificate based authentication or identify verification, separate from the integrity exchange, where the SSL ciphers really come in. The certificate is only good for verifying the server "X" is really "X" and not "x". The ciphers are, instead, used to provide a mechanism where you establish the symmetric key for data ...


1

A digital certificate, especially the most-common X.509 format used for TLS, has a number of parts. Three of the most important are the subject name, the subject public key, and the issuer signature. The first two tell you who the certificate is for (such as "*.stackexchange.com"), and what the public key that corresponds to that entity's private key is. ...


1

For instance the procedure never asks you to create a private key, instead they magically create one for you. I know cryptography is magic, but in this case it is also secure... :-) Because when using a Let's Encrypt client the key pair is generated locally on your server and not send to Let's Encrypt servers* - in contrast to some other commercial CAs, ...


1

Thomas Pornin's answer is good, but a little outdated. Support for Name Constraints is growing. I've found that OpenSSL 1.0.1k and Windows 7 support the extension. Test Using XCA, I created a self-signed CA certificate, and added a critical Name Constraints extension for .lab.example.com, by adding the following line on the "Advanced" tab during ...


1

You can't do this, you will have to apply for a new certificate. There are special types of certificates that apply for multiple previously specified domains at once.



Only top voted, non community-wiki answers of a minimum length are eligible