Hot answers tagged

49

It is a certificate of a content delivery network – a U.S. company Incapsula Inc. – intercepting your whole communication with the bank. The certificate itself does not pose a direct risk to customers' data, but: Is this considered a bad practice? Unlike the other answers, I would say it is not normal and the situation indicates a certain level of ...


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

There is no thumbprint included in the certificate. What is included is a signature which is used to build the trust chain. The thumbprint (or fingerprint) is just a hash over the certificate to make it easier for humans to compare certificates. It is not included but computed when needed.


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

Notice incapsula.com in the subject. Incapsula is a company that offers web application security that includes WAF, DDOS protection and a few more services. My guess is that your banks website is actually proxied through their server and so are all those other sites. That server gives out the same certificate on all those sites because they are all actually ...


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

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.


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

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 ...


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

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. ...


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 ...


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.


3

Certificate Transparency solves a different problem from CRLs and OCSP. OCSP and CRLs handle the problem of certificate revocation. The CA is offering resolution for mistakes and bad actions on the part of the CA's users. That is, the CA is assumed to be infinitely trustworthy, but a certificate may need to be revoked because of poor key management or some ...


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

The sever sends its certificate during the TLS handshake and the client verifies its trust path. In the first step the client matches the common name (CN) field with the server's hostname (it does not compare the certificates). Then the client verifies the trust path, i.e. whether the certificate presented by the server is signed by an entity whose ...


3

This may be normal. Banks often consolidate, purchase, cross-market, and do all sorts of things that mean that they're answering to more than one name. It is not unusual for a bank to have numerous SAN entries to allow all their varied customers to get to their web site, even if they're a customer of a bank purchased by a bank purchased by a bank purchased ...


3

openssl s_client does not use Server Name Indication (SNI) by default while the browser does. To force SNI use the -servername parameter: $ openssl s_client -connect objective-see.com:443 -servername objective-see.com |\ openssl x509 -text ... Subject: CN=objective-see.com


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 ...


2

Not necessarily a concrete security risk, as soon as you (the IT admin) are prepared to the new risks. Strenghtened procedures If you have a single certificate for many domains, it's a single point of failure and weakest chain ring. You need to enforce expensive IT procedures to keep its private key "eyes only" or better "HTTPS server only". Compromise of ...


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 ...


2

The primary difference is that PGP does not trust a set of central authorities while SSL does. In SSL the certificate authorities do the required checks and then certify that the identity of the certificate holder is correct for the level of certification. We trust the CA's decisions and trust who they trust. The different certificate types theoretically ...


2

The short answer is that while yes you can reuse the CSR, it doesn't mean you should. It's worth considering that encryption methods can improve over time (e.g., generating RSA keys @ 2048 or 4096 vs 1024 awhile back, sha256 vs. sha512, etc) so it's probably best to just generate a new one considering how trivial it is and increasing the private key ...


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

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