Tag Info

New answers tagged

1

If you are asking can you use the same keypair, yes you can always use the same keypair. Your first and second certs could have also used the same keypair. If you mean will the CSR do a reissue instead of requiring you to purchase a new cert? That isn't a technical question. They certainly "can" but most will not. Any change to the cert will require ...


0

Finally I did it with BouncyCastle library. PKCS#7 is a complex format, also called CMS. Sun JCE has no direct support to PKCS#7. This is the code that I used to extract my content: // Loading the file first File f = new File("myFile.p7b"); byte[] buffer = new byte[(int) f.length()]; DataInputStream in = new DataInputStream(new ...


2

Yes it is true. When certificate is self-signed, then issuer and subject field contains the same value. Also, there will be only this one certificate in the certificate path.


1

It depended on the root CA's and it's connection with another CA's. However generally in client authentication, you show your certificate to it, it will check this certificate parent's since it get the root CA. And what happen if the root CA certificate not valid? I think you should report this problem to support team of that CA.


3

What does this mean? The certificate changed, as shown by the different SHA1 hashes. The MD5 hash field is no longer relevant as Firefox deprecated them. Can I trust the certificate? No, if it changed without the admin (ie. your) intervention, you should be highly suspicious. How can I check that my certificate is still valid, created by me, ...


7

This is not for "certificates above the end-entity" but for "root certificates" only. In pure X.509, there is no such thing as a "root certificate". There are certificates, and there are trust anchors. A certificate contains a public key, the name of the entity that owns that key, and is signed by another entity (an "upper certification authority"). This ...


1

Isn't identity proven by the advocate (higher authority) signing a hash of the certificate? Root certificates are built into the system (or shipped with the browser). They are the end of the trust chain and there is no higher authority which signed them. They are self-signed, but only because there has to be some signature. The signature does not need ...


20

There is a standard for that, and, more generally, for all communications with a PKI. It is called CMP. Revocation requests are specified in section 5.3.9. Now, finding a PKI that actually implements CMP... this may be challenging.


6

If the entity is supposed to sign CRL but not certificates, then it is not a CA -- it is a CRL issuer. It is often called an indirect CRL issuer because, by definition, it is distinct from the CA that issued the certificates whose revocation status is specified by the CRL. A certificate may be validated as a CA only if (among other things) it has a Basic ...


0

Some of these older Root Certificates have been used to generate 'Time Stamping' or 'Code Signing' certificates. This means a piece of executable code has been digitally signed way back. These Root Certs may still be needed, so your PC can validate that the code signing was valid AT THE TIME OF SIGNING. Which can be of course also way back. Deleting these ...


3

No, the only way to change the validity date is to re-issue. The reason is that the certificate's hash is calculated after the rest of the certificate is written, editing that field would cause the certificate's hash to change. If the hash is changed anyone else checking the certificate will know it has been altered, but won't be able to tell what changed. ...


1

I would recommend that you obtain documentation and demonstration of the vulnerability as you are aware of it. Ideally if you can have this verified entirely by a third party, who has been read in to the situation. To avoid issues of integrity or vendor repudiation of the advice on the vulnerability against you, additional proof by demonstration/execution ...


1

As Mike Scott has said, Let's Encrypt describes how they will be authenticating certificates. Remember: SSL issuance practices are entirely standardized by the CAB Forum. Let's Encrypt is following the same rules that all other CAs are required to follow. They are just doing it via the command line. The certificates they will be issuing match the issuing ...


3

Ryan Sleevi has very good advice regarding this. Before sounding off too many alarms, I would contact the Chromium Security Team as he has advised, just to make sure that you are not misunderstanding anything. Have you checked your vulnerability against the CAB Forum Baseline Requirements to see if the execution of your vulnerability breaks those rules: ...


0

Operating system and browser vendors might be a good place to report such a vulnerability to since they manage the root CA lists. Here are a few relevant links: www.google.com/about/appsecurity/ www.mozilla.org/en-US/about/governance/policies/security-group/bugs/ www.apple.com/support/security/ technet.microsoft.com/en-us/security/ff852094.aspx


18

When unsure, you can also contact CERT: https://forms.cert.org/VulReport/ They have experience in dealing with even very serious security vulnerabilities, and are generally considered a trusted party. At least they can confirm that your assessment of the vulnerability is correct, and document your part in finding it. While CERT generally advises you to ...


33

Such a claim is generally quite serious. While reaching out to the vendor in question is a responsible matter, you should certainly consider notifying the relevant root store security teams, since they are responsible for designing, evaluating, and applying the security controls to prevent this, and will likely need to directly work with the CA to ascertain ...


23

Congratulations! Sounds like a major find. First, generate some proof. The github.com SSL certificate sounds like a great start. Make sure you keep all the network traces you need to show exactly what happened. You need to determine if you broke any laws or T&Cs while doing this. If the CA does not have a bug bounty, you almost certainly did. In that ...


64

It sounds like your issue is that this vulnerability is bigger than you know what to do with. The rules of responsible disclosure, as decribed here, say that you should contact the vendor and negotiate a period of time - between 1 week and 6 months, depending on the depth of the changes required - in which they can implement a patch, revoke and re-issue ...



Top 50 recent answers are included