"Private certificate"? Issued certificates are signed by the CA's root private key. The root certificate is just a convenient means of packaging the corresponding public key. Certificates don't sign things. Private keys sign things.
If I have a CA's (any CA's: Tom Brennan's or DigiCert's) root private key, I can sign certificates and they are no different from any other certificate signed by that CA. That private key corresponds to the public key in their CA root certificate, and the digital signature will validate with no issue. Yes, you need the CA's public key to validate the signature, but CA public keys are widely (publicly!) available. True, you should not trust a purported CA certificate sent by e-mail. It could be a phony certificate with a public key that corresponded to a bad actor's private key. My sole point is that trusting an ad hoc CA operated on some individual's PC carries a significant risk. Charles On Tue, 29 Aug 2023 16:57:25 +0100, Colin Paice <colinpai...@gmail.com> wrote: > I thought that signing a certificate meant the CA encrypted the checksum >of the certificate. For me to validate the certificate I need the CAs >public certificate to be able to decrypt the check sum, and compare it with >what I calculated. If I do not have the CA's public certificate I cannot >do this. You can take the CA's private certificate and create as many >certificates as you like - but as I do not have the public certificate, >they will not validate. >If you send me the CA's public certificate, I could validate what it >issued, but I would be worried that a bad actor had intercepted my mail >and substituted a different CA certificate. If your CA certificate has >been certified by the standard CA companies, then I can validate it and >quite happily use it. >So no, you cannot create certificates, sign them and make me believe they >came from a bona fida company - unless I do something stupid. >Colin > >On Tue, 29 Aug 2023 at 16:46, Charles Mills <charl...@mcn.org> wrote: > >> Don't want to get into one of the peeing contests that have become all too >> common here. >> >> Let me just say that never mind any enterprise PKI CA constraints, I think >> Tom was talking about OpenSSL on a PC. OpenSSL stores private keys -- >> private keys -- in a pretty accessible format. If I can get into Tom's PC >> -- perhaps while he is at lunch, or with a clever phish -- and get that >> private key, then I can generate server certificates for any site in the >> world and Tom's associates will trust those certificates. >> >> Not criticizing Tom or his processes here. Just pointing out to readers >> that there are some significant risks in general to the approach of "oh, I >> will just create an ad hoc CA and have my users trust it." Trusting a CA is >> implicitly trusting everything that anyone does with its root private key. >> >> Yes, it is no different in some ways than trusting DigiCert. The >> difference is that DigiCert has very rigorous protocols for protecting its >> root private keys. OpenSSL does not. >> >> Charles >> >> On Tue, 29 Aug 2023 09:23:16 -0500, Grant Taylor < >> gtay...@tnetconsulting.net> wrote: >> >> >On 8/29/23 8:31 AM, Charles Mills wrote: >> >> Just being a security PITA here, but that solution makes the security >> >> of their systems subject to whatever safeguards you do or do not put >> >> on yours. >> > >> >Remember, Certificate Authorities can be constrained. E.g. it's >> >possible to create an Enterprise Certificate Authority that can only >> >sign things in the enterprise.example.net domain and nothing outside of >> >it. Thereby significantly limiting exposure to things outside of the >> >enterprise. >> > >> >> If I can extract the CA private key from your PC than it is trivial >> >> for me to create a www.chase.com certificate that will be trusted by >> >> their browsers without any question, and mount a man-in-the-middle >> >> attack on their banking. >> > >> >I question the veracity of that statement. >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
