[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: Digital Certificate - REKEY process with a new CA
From:       Wai Choi <wchoi () US ! IBM ! COM>
Date:       2022-04-28 23:41:12
Message-ID: BN8PR15MB3121780BBAB707C1928A4E2881FD9 () BN8PR15MB3121 ! namprd15 ! prod ! outlook ! com
[Download RAW message or body]

Right... this cycles back to the basic point similar to the key management practice \
suggested by Greg earlier - '...to rotate keys whenever your key management policy \
says to rotate them.  And your key management policy should be based on the \
regulations that apply to your organization.' 

For certificate management, it could be:

'Your certificate management policy should be based on the regulations that apply to \
your organization, which includes:  For CA certs - 
1) List of trusted CAs, 
2) How to add a trusted CA to the list ( self-generated, from the web site, from \
email...),  3) How to let the communicating parties get the root CA cert, 
...
For end-entity certs that operate with private key - 
1) Required key type, key size and validity period, 
2) Renewal time before a cert expires, 
....'

I just started with some basic points and hope others can chime in to beef up a \
general policy that would be useful for our members.

Wai Choi, CISSP
RACF/PKI Design and Development

-----Original Message-----
From: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU> On Behalf Of Charles Mills
Sent: Thursday, April 28, 2022 6:09 PM
To: RACF-L@LISTSERV.UGA.EDU
Subject: [EXTERNAL] Re: Digital Certificate - REKEY process with a new CA

And you probably need to install and TRUST any Intermediate and Root certificates \
sent by CA Y.

The connection partner may or may not already have the CA Y root. (They don't need to \
install the Intermediates; your application will automatically send them as part of \
the protocol.)

Actually you should tell them to download the CA Y root from Y's Web site, not send \
it to them. If you send it to them, then there is the admittedly very remote \
possibility that someone alters it in transit (or, frankly, from their point of view, \
that you are a bad guy and are sending them a bogus root certificate). 

Charles


-----Original Message-----
From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of Wai Choi
Sent: Thursday, April 28, 2022 2:43 PM
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: Digital Certificate - REKEY process with a new CA

Rogerio,

The cert created with REKEY is ok. But after rekey, you can't do ROLLOVER since it is \
issued by a different CA. You can update the keyring with the new CA "Y" (by RACDCERT \
ADD and CONNECT). And make sure you send the new CA "Y" (assume CA "Y" is the root \
CA) to the other party.

Wai Choi, CISSP
RACF/PKI Design and Development

-----Original Message-----
From: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU> On Behalf Of Rogerio Eugenio \
                Malaquias Camargo
Sent: Thursday, April 28, 2022 7:52 AM
To: RACF-L@LISTSERV.UGA.EDU
Subject: [EXTERNAL] Digital Certificate - REKEY process with a new CA

Good Morning!

Regarding Certificates,  I am really not sure if it will work, but I would like your \
thoughts before performing my REKEY /  ROLLOUT process.

My current cert, signed by CA named  "X" ,  will expire end of May.

My customer decided to no longer use CA "X" ,  but use  CA "Y"  from now on.

Does anyone see any issue if I REKEY my current cert (which was signed by CA
"X")   and  send the CSR to be signed by the new CA "Y"  ?

Thanks a lot for any input.


[prev in list] [next in list] [prev in thread] [next in thread]