fapifta commented on PR #5163: URL: https://github.com/apache/ozone/pull/5163#issuecomment-1724060331
> @fapifta , It's because the serial ID is used when constructing the subject of each service, like scm-sub-$ID, otherwise the old and new certificate will always have the same subject. This subject is constructed by DN/OM/RECON itself, and is included in the PKCS10CertificationRequest, which is passed to SCM later. The first code edition I tried, was trying to extract the subject name from PKCS10CertificationRequest, update it, and reset the subject in PKCS10CertificationRequest with the new value. But soon I found it's hard to do that because the PKCS10CertificationRequest is not mutable. So that's why the current solution is used. I am still unsure... I understand that the sub-ca certificate of SCM uses the certificate ID in the subject, however all the other services (DN/OM/RECON) does not, so I think other services does not need the sequence ID generator to supply them a certificate ID while they are generating the CSR request. SCM using the sequence ID in the certificate's Subject I am not convinced is necessary at this cost of introducing a new proto message, and additional handling of that message. I would like to understand if that serialID in the subject is used for anything, especially because the certificate serial id is available in a separate field in the certificate. If it is not needed I'd rather get rid of the certificate's serial id in the subject field, and spare the complexity of extending the protocol, hence the doubt. So far I did not find a specific use for that serialID in the subject. What do you think can we potentially get rid of it, and rely on the certificate's serialID field where certificate serial id is needed and we do not do so already, and then just use the generator when signing a certificate to generate the serial ID? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
