CAcert Key File question.

Hi,

I am new to SSL Certificates. I tried first to sign my own certificate but my email client is complaining about my certificate being "not trusted" and then connecting as:
Code:
auth = plain
For the record I am running FreeBSD 9.1 and trying to get Dovecot 1 to authenticate the IMAPS protocol.

I have created an account at CAcert and generated a certificate. I can't find how to create a matching key. A little help is greatly appreciated.

regards,

mroussin51
 
Breaking News!!

Hello again,

I just learned that the private key was created in the browser when the certificate was made. I don't yet know how to retrieve the key so I want to relay that my Browser is Chrome Version 28.0.1500.72 m and that is on Windows 8.

I appreciate your assistance,

Mike
 
I never used CAcert, so the following is not guaranteed to work.

CAcert is just another Certification Authority, and in order to obtain server/service certificates, you need to generate a .csr-file (i.e. a Certificate Signing Request) and upload it to CAcert.

I would generate it using OpenSSL, however the link given above shows other options.

Code:
# create a server.csr using a private key that is saved by password
$ openssl genrsa -aes256 -out server.key 2048
$ openssl req -new -key server.key -out server.csr

# create a service.csr using a private key without password protection
$ openssl genrsa -out service.key 2048
$ openssl req -new -key service.key -out service.csr

The .key files are your private keys, and I guess these are what you are looking for.

I usually create a generic server.csr, for the second-level domain, e.g. CN=mydom.net, and a service.csr for wildcard third-level domains CN=*.mydom.net. Then respective .crt-files obtained from the CA are then server.crt, and service.crt.

Note that service.crt is valid for all of the sub-domains, e.g. www.mydom.net, mail.mydom.net, svn.mydom.net, etc, while server.crt is only valid for the exact domain that has been entered as Common Name (CN). This is my habit and not even a recommendation. Make only sure that the CN matches your domains, either exactly or by utilizing wildcards, otherwise the clients will error-out.

In any case, you need to store the certificate of the CA, either that of CAcert, or the one of your own CA into the certificate store of your clients. And once your arrived at that point, there is technically no difference at all, whether you obtained the certificates by your own CA authority or by CAcert.

Nowadays, I tend to trust only my own CAs and certificates. My whole life, I laughed about the tin foil heads, however, for the time being, I started to be more careful, especially after General Alexander stated that the NSA is happily doing everything what is technically feasible (because everybody else is doing it also). CAcert is based in Australia, which is one of the preferred partners of the NSA, and for sure it is technically feasible to compromise the certificate chain by the way of manipulating the Certification Authority.
 
Thanks again rolfheinrich

Greetings,

I learned that if I make my certificate on a Linux machine it is very easy to find the key. You have brought up something that I was very ignorant about. I need to have a public key and certificate on the client machine. Which I was wondering about for a couple days now. I thought that this should work something like ssh secure keys.

Thanks for sharing your knowledge about certificates. Your time is appreciated. I am going to advance myself and see to it it does not go to waste.

Regards,

Mike
 
Just for the record, certificates alone can not be used for eavesdropping, they are only a method of verifying digital identities. This means that the issuer of the certificate can not give you certificate that some outside party (NSA) could use for spying purposes. Of course if you (as the user connecting to an SSL site) choose to trust any certificate that is not signed by a trusted third party all bets are off but that's a another matter.
 
kpa said:
Just for the record, certificates alone can not be used for eavesdropping, they are only a method of verifying digital identities. This means that the issuer of the certificate can not give you certificate that some outside party (NSA) could use for spying purposes. Of course if you (as the user connecting to an SSL site) choose to trust any certificate that is not signed by a trusted 3rd party all bets are off but that's a another matter.

You are touching the point somehow, but you don't hit it exactly.

If the outside third party is able to place fully signed duplicate certificates under the hood of any root certification authority, and if this third party is able to redirect TLS traffic to its own server which uses the perfectly falsified certificate for identification, then this third party could of course decrypt all the traffic, and encrypt it again for another TLS connection to the original destination. For the victim, this perfect MITM is totally transparent. Of course only the big guys together with their closest 4 friends are able to make themselves up for a perfect MITM, I mean those guys who got a annual budget of 75 GigaUS$. Don't you think that for a 1 MegaUS$ (more or less) they won't find any co-worker of a CA who would give them access to the certificate store? This is peanuts for them, they can spent 75000 times 1 million.
 
You will be able to distinguish the duplicate certificate by looking the details of it, the serial number and other information will be different for different certificates for the same CN. With 100% certainty the public key (the heart of the certificate!) will be different because otherwise we wouldn't be talking about public key cryptography. Of course you have to know what to look for.

The scheme you're describing assumes that all traffic is forcefully fed trough a decrypting SSL proxy that has the duplicate certificate. That wouldn't go unnoticed.

On top of that there is great focus on the very issue now by independent security researchers who run MITM scans by themselves comparing certificates from the known large SSL sites against reported certificates that looks fishy.
 
Back
Top