New answers tagged certificate-authority
5
Trusted CA certificates are validated by a third party, called Certificate Authority. In a cryptographic sense, CAs are a trusted third party (TTP) validation authority in a public-key infrastructure (PKI):
The primary role of the CA is to digitally sign and publish the public
key bound to a given user. This is done using the CA's own private
key, so ...
3
The server certificate is sent by the server, to be validated by the client. The client certificate is sent by the client, to be validated by the server. They live in different worlds and have no need whatsoever to relate to the same certificate authority.
For client certificate validation with Apache, see this documentation. The server will need to ...
6
According to your comments to other answers, you actually want to
sign a pdf file with [your] certificate, then have this signature saved and appended to the pdf [you]'ve just signed.
(BTW, you sign with the private key associated with the public key in your certificate, not with the certificate itself, but that's a detail.)
I assume you want to ...
1
If you want to sign a PDF, most PDF writers, and some versions of the reader-only will have a built in mechanism for signing, and some even for timestamping. It will ask you to provide your certificate file and then it will apply the digital signature into the file. PDFs in particular have this mechanism built into the format, but it is also possible to sign ...
1
Your question is really two different questions. A certificate only needs to be signed by another certificate if there needs to be a chain of trust. For example, a root CA will sign the certificates they issue so that anyone trying to verify the certificate will know that it is trusted by the CA. You can do this kind of chaining with any certificate that ...
1
A certificate always contains a signature, but on itself, not on some PDF document. This signature is an integral part of the certificate and has been computed by the CA which issued the certificate; this is by verifying this signature that any software can gain some trust in the contents of the certificate. All of this happens independently of any PDF file, ...
1
As the certificate is registered to you and fields completed with your details, the certificate is your digital signature. You don't add a digital signature to the certificate.
You need a certificate to be issued by a CA (which you could create). Then add the certificate to your trusted certs (if self-signed or not from an standard recognised CA). When you ...
3
A CA must indeed publish CRL regularly, and if the CA is offline, then human intervention is needed. Each CRL has an issuance date (thisUpdate) and a provisional date of next publication (nextUpdate) which everybody uses as an end-of-validity date for the CRL. The next CRL must be published before reaching the nextUpdate date of the current CRL; otherwise, ...
2
There's almost no threat at all. Do you trust your own computer not to attempt an MITM attack against you? Then there ought to be no problem.
When you try to access localhost, the network adapter isn't even touched. If someone stole the key, the could use it to convince their own computer that it is itself. Or any computer that they have access to (if they ...
3
With such a certificate, any system who trusts your internal CA will trust a server running on "localhost" as being genuine, i.e. running really on "localhost". But "localhost" can be reached, network wise, only locally, so if your client successfully connects to https://localhost/whatever then it already knows that it is talking with the local machine. ...
2
I don't see any more significant threat for localhost than any other certificate. The main abuse of an SSL cert is to convince a system that you are the system they want to talk to when you are not, but an attacker couldn't compromise the traffic going to localhost unless the client computer is already compromised at a fairly low level (at least has access ...
0
I solved the problem. I installed the WinHttpCertCfg tool and granted access to the private key. The command that worked for me is:
WinHttpCertCfg.exe -g -c LOCAL_MACHINE\MY -s "" -a EVERYONE
3
openssl is a very good command line tool that I have used to create self signed certificates. This will allow you to specify the values for each and every field in the certificate and it is available for both Linux and Windows.
basically you can create a self signed certificate using openssl in just one command
openssl req -x509 -newkey rsa:2048 -keyout ...
8
There is a handy script distributed alongside openssl, CA.sh to do most of this stuff. Its location is distribution specific. In Debian and derivatives you can locate it using:
# apt-file search CA.sh
openssl: /usr/lib/ssl/misc/CA.sh
And RedHat and derivatives the (approximate) equivalent is:
# yum provides */CA
1:openssl-1.0.1e-4.fc18.x86_64 : Utilities ...
0
X509Store store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
You're using the LocalMachine store. Either put your certificates are 'Machine Certificates' in mmc, (elevated MMC -> certificate snap-in -> Computer Account), or use the CurrentUser store.
Also this might be a better question for StackExchange since it's C#/Programming ...
3
Your principles are correct, but the particulars can be a devil to set right.
Indeed, the general schema is that:
The client needs to validate the certificate from the server, i.e. verify that the certificate has been issued (signed) by a trusted CA, and that the alleged server certificate contains the name of the server.
Similarly, the server needs to ...
Top 50 recent answers are included
