New answers tagged

3

Generally speaking certificates (X.509) contains the public key (of the corresponding private key) that was used to sign the certificate. You can't make any inferences of authenticity of the certificate (and it's attributes) if there is no signature or public key. I suspect your difficulty has to do with how the certificate and keys are distributed. ...


0

There is actually more to putting certificates on the card than just a software. You have two options when putting certificates on the card: The private key is generated on the card alongside with the CSR that is sent to the CA for signing and the cert is then installed on the card. This is the preferred option for authentication certificates, the fact that ...


0

You should use HTTPS Public Key Pinning or Certificate Pinning to simplify. In this case, your app's business logic will never perform crypto operations on the server payload. The underlying transport level (TLS) is initialized with the list of keys/certificates to accept to consider the connection as trusted. You should also accept that a determined ...


2

You really do not need to worry about that, that is the reason its called public key. You should instead seek to secure your private key, because its the key you actually use to sign the data and it is only required to use the public key pair to verify the signature on the data. If an attacker uses another public key that is different from the one that was ...


-1

The Idea of a certificate Is like your passport. A trusted organization (Government) vouches to any or all recipients of the passport that Mr Smith has passportID XYZ. So a certificate will always bind a human readable name of a person or an entity to a public key that everyone can see. The private key is NEVER EVER sent out to anyone and the moment it does, ...


0

Why are you trying to verify the public key after you obtained it from your trusted server over a TLS connection? You are mixing things. Certificates are used to bind a human-readable name/organization to their corresponding public key. Usually a publicly trusted entity (trusted by all potential clients) “vouches” that Mr. Smith has public key XYZ and that’s ...


1

It is common for code signing certificates to be hardware backed, since in the past there was lots of misuse by stolen code signing certificates. Hardware backing a certificate means that the actual hardware needs to be present when signing. The signing itself happens on the hardware itself, i.e. the private key never leaves the hardware. The hardware is ...


2

I don't see why the proposed model would not be better but maybe I miss something ? The approach of requiring multiple valid trust anchors instead of one is a sound approach in theory and is actually used in practice within OpenPGP. There the trust into a key depends on how many trusted endorsers have signed the key and how much trust one itself has into ...


1

You can't generate a CSR using only a publickey, you need the privatekey, which for historical reasons PGP calls the 'secret' key. Also once you get a cert, to do anything useful with it you need the privatekey. (Both PGP and OpenSSL-compatible privatekey file formats include the publickey, so you don't need that separately, although depending on the ...


1

So, I'll admit, OpenPGP is not something I have much more than a superficial knowledge of. I always end up back in the docs when I have to explain something - it's just not a useful technology for most of what I do (web app development in the cloud). Go/No-Go Decision Mileage will vary, somewhat, depending on your key type. The CA will have a specific set ...


1

I work for Signer.Digital and it provides free JavaScript API for digital signing from modern browsers. The USB token or Smartcard is accessed on browsers using browser extension which is freely available. Installation steps are given on demo portal. The similar software and libraries is available for Windows and Linux for direct deployment or integration ...


0

To me, this implies that openssl can verify the immediate cert, but not the server cert. That's right. What you are missing is that openssl verify [options] file1 file2 ... validates (the one/first cert in) each file1, file2, etc. independently. What is happening is: OpenSSL tries to validate intermediate_cert.pem against the root ca_cert.pem. This ...


Top 50 recent answers are included