Mr. Butturini, this looks to be what I was looking for. As a person who is starting out and trying to figure a lot of these things out, I find this list to be very informative. I just want to say that I really appreciate how willing to share information everyone is.
Thanks, Sam -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Butturini, Russell Sent: Tuesday, April 26, 2011 7:20 AM To: PaulDotCom Security Weekly Mailing List Subject: Re: [Pauldotcom] CA Question If this is a Cisco router (I figure this is a good guess), the keys must have been generated with the exportable option when the certificate was issued in order to move them. The command would look something like this Crypto key generate rsa modulus 2048 exportable label CERT_KEYS Then you can export the keys to flash or the terminal using the crypto key export command. Just make sure to name your trustpoint on the new router the same as the filename of your keys when you move them to the new router. Of course, if this isn't a cisco router, this is all irrelevant :-) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dan Burrowes Sent: Monday, April 25, 2011 9:39 PM To: PaulDotCom Security Weekly Mailing List Subject: Re: [Pauldotcom] CA Question > This may be a bit of a silly newb question, but I was wondering if it is > possible to transfer a certificate that has been signed by a CA (i.e. Thawte, > Verisign) to a new device. If you're talking about SSL, then yes, it is possible. As long as the domain name (or alternately, the FQDN, depending on whether or not the cert is a "wildcard cert") that the certificate was issued to when used on RouterA is the same as the domain name that will be used for RouterB, then it will work, provided that RouterB has the private and public keys that RouterA was using. Certs only say that "this device has cert Y which the CA verifies belongs to domain Z". Someone correct me if I'm wrong, but with SSL, there is no option for hardware hashing or anything to tie the keys to particular hardware. The keys can just be transferred to another device, in which case the cert will again say "this device has cert Y which the CA verifies belongs to domain Z". This is the reason why you can create the keys on a system that is different from the system you will actually use the cert on. This is also the reason why if an attacker steals your private keys, it's "game over" -- she can impersonate you (assuming she also controls DNS), and the CA will still say "duh...yup, it's valid...nothing to see here...". Correct me if I'm wrong (again), but this is one of the things that the Perspectives[1] project helps protect against. Multiple servers from multiple locations frequently check if the cert has changed, or if the IP the cert was previously found at is the same as the current IP. --dan [1] http://www.networknotary.org/ _______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com ****************************************************************************** This email contains confidential and proprietary information and is not to be used or disclosed to anyone other than the named recipient of this email, and is to be used only for the intended purpose of this communication. ****************************************************************************** _______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com _______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
