New answers tagged

2

Normally, there will be no warning as the certificate is signed by a trusted CA. Wrong. Since the subject of the certificate ( www.randomname.com) does not match the URL (www.google.com) the validation will fail and the browser complain. It does not matter if this is "only" a redirect, i.e. even for the domain you redirect from you need a proper ...


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


0

1) If the intermediate certificate (B) is trusted - that is, it is a valid signing certificate, not expired, not tampered with, and not revoked - then it being in the trust store is enough that the TLS client doesn't need to continue up the chain in order to verify the leaf certificate. However, that "not tampered with" thing requires having a trusted ...


0

IIRC, and I could be wrong, This is because it was using self signed certs that were generated psuedo on-the-fly. Because of this, if you reverse engineer the interception mechanism you could extract the private key


-2

Every operating system installer packages are signed. In Windows for example, when you download Firefox Installer Stub, you can check it's properties by right-clicking on the exe file and going to "Signature" tab: Then, click on "Details" to see more, you will see "Signer Information" and whatever it's "OK" which is checked with Windows built-in ...


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


0

Firstly, you are right, it is a recursive problem. SSL is sort of a house of cards because you always have to trust something, including the folks that are telling you who to trust. A number of experts have predicted the collapse of SSL: Security Collapse in the HTTPS Market SSL/TLS encryption and the vacant lot scam: Too big to fail How is SSL ...


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.


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


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


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


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


0

The browser examines each certificate in the chain that terminates with a self-signed Trusted Root Certificate of the Certification Authority. This would be in the local certificate store. It verifies that the signature is valid, that the current time is within the validity period of each certificate as well as checking the CRL published location (http or ...


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


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


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


0

Certificate authority is the one issuing SSL and other digital certificates. It is highly trusted entity who verifies the information provided by web server such as its domain name, public key, the company’s identity. If all the information provided, are legal then the CA will issue the respective SSL certificate duly signed using its private key. Moreover ...


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


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.


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.


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.


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


0

What we consider to be a Certificate Authority is represented by a "Trusted Root Certificate" which is a self-signed certificate that is delivered by secure means (most often during the OS or browser installation process.) Typically a single Certificate Authority issues only one Trusted Root certificate, but not always. A company that operates as a CA is ...


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


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


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


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


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


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


0

Your question is scattershot and not very clear so this can't be a complete answer the firstname of the self sign has to be my domain name? Only for SSL/TLS server -- mostly. What Java keytool prompts as first and last name is the CommonName attribute in the Subject name (also Issuer name for selfsigned). For SSL/TLS servers it used to be required that ...


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


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


0

A CA is a certificate authority which means a third party that attests of your identity. It is possible to use self-signed certificates for encryption but it doesn't allow attesting that the certificate comes from the proper (authorized) machine. Anyone could set up a self-signed certificate for your domain name. If you really wanted to create your own ...


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


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


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.


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


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



Top 50 recent answers are included