To read X509, man (s3) PEM_read_[bio_]X509 or d2i_X509[_fp,bio] . There aren't man pages for
the non-I/O functions and similarly for X509_REQ other than I/O, but they're pretty obvious in x509.h: you want X509_get_$various and X509_REQ_set_$various . When I have a question on these I usually just look at apps/x509.c and apps/req.c and see what they do. I would say the new publickey in the CSR is *extracted* from the new privatekey rather than generated, since generation is normally used to mean a new key. In fact this is implicit: if you have an EVP_PKEY containing the keypair (private+public) and use it to X509_REQ_set_pubkey, that internally encodes the key to SubjectPublicKeyInfo format which inherently uses only the public components of the key. If you are using a local CA, it must use an Issuer that identifies itself. If the original customer cert was from a different CA, that cannot be the same Issuer. Trying to make them the same is not only fraudulent, but will frequently cause chaining and validation to fail. Serial is required unique for all certs under one Issuer, so if the CA/Issuer is different it is unlikely you can reliably arrange for the same serial(s) to be available. If the original customer cert was from your same local CA, it will (or can) make Issuer the same. Proper CAs should not assign a duplicate serial, but depending on your CA you might convince it to, since in a sense this cert is intended to replace the other one. But I doubt you need to; anything (server?) you communicate with for which serial - or even issuer+serial - matters would be extremely weird. For the CA-related extensions like AKI, CRL, OCSP, AIA, policy, your CA must use correct values for itself. If it tries to use values for some other CA, then when you try to use the cert for SSL your peer will check with the other CA which will quite correctly identify your cert as unissued and fraudulent. As I said you probably can (and should) request SAN like the original cert - I expect that to work either with your local CA or a public CA (although with a public CA it may cost extra) since it identifies normal cert subjects. That only leaves KU and EKU; depending on how your local CA operates, you may be able to request those. Is this local CA delegated under a public CA, or one your organization just made up? In the latter case, if the problems you want to troubleshoot involve anybody else's systems, I wouldn't expect them to trust certs from your local CA at all. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Kamalraj Madhurakasan Sent: Friday, October 04, 2013 08:17 To: openssl-users@openssl.org Subject: *** Spam *** Re: CSR from old certificate and signing it using new private key Hello Dave, Please see inline. Assuming by "get it signed" you mean signing the CSR, not getting a cert issued from the CSR which many people wrongly think is "signing the CSR": yes OpenSSL has APIs for both X509 (cert) and X509_REQ. [Kamalraj] If you don't mind, can you share those APIs You can read in a cert (PEM or DER), extract fields/extensions from it as desired and put them in a "req" along with a new subject-public-key, and sign with the corresponding (new) private-key. [Kamalraj] the public key must be generated from the new private key right? And write that out and send it to a CA, and prove to them you are authorized to act for/as that subject name(s). But you can't copy anywhere near "all" fields/extensions. It looks to me like the only ones you need are Subject(name) and if used SubjectAlternativeNames. You want to replace subjectkey, and if used SKI. A CSR cannot specify Issuer, serial, validity, and a CA can't let you specify AKI, CRL/OCSP access, Authority access, policies etc.You might be able to request KU or EKU, but I think most CAs will hardcode them. [Kamalraj] If I use my local CA, then it is possible to ask this CA to use those all extensions while signing the new certificate right? You might even be able to do this without an actual program by scripting commandline x509 plus some parsing and req, but I would worry that was fragile. Note that there is a -x509toreq option on x509 but it doesn't do what you want: it copies the subject name and the (old) subject pubkey - and no extensions. [Kamalraj] I had plans to use the command line options. Now, as per your input I will go ahead and create a binary that will use those APIs to create a new CSR and sign using local CA. Thanks Kamalraj On Fri, Oct 4, 2013 at 4:02 AM, Dave Thompson <dthomp...@prinpay.com> wrote: Assuming by "get it signed" you mean signing the CSR, not getting a cert issued from the CSR which many people wrongly think is "signing the CSR": yes OpenSSL has APIs for both X509 (cert) and X509_REQ. You can read in a cert (PEM or DER), extract fields/extensions from it as desired and put them in a "req" along with a new subject-public-key, and sign with the corresponding (new) private-key. And write that out and send it to a CA, and prove to them you are authorized to act for/as that subject name(s). But you can't copy anywhere near "all" fields/extensions. It looks to me like the only ones you need are Subject(name) and if used SubjectAlternativeNames. You want to replace subjectkey, and if used SKI. A CSR cannot specify Issuer, serial, validity, and a CA can't let you specify AKI, CRL/OCSP access, Authority access, policies etc. You might be able to request KU or EKU, but I think most CAs will hardcode them. You might even be able to do this without an actual program by scripting commandline x509 plus some parsing and req, but I would worry that was fragile. Note that there is a -x509toreq option on x509 but it doesn't do what you want: it copies the subject name and the (old) subject pubkey - and no extensions. From: <mailto:owner-openssl-us...@openssl.org> owner-openssl-us...@openssl.org [ <mailto:owner-openssl-us...@openssl.org> mailto:owner-openssl-us...@openssl.org] On Behalf Of Kamalraj Madhurakasan Sent: Thursday, October 03, 2013 04:15 To: <mailto:openssl-users@openssl.org> openssl-users@openssl.org Subject: *** Spam *** CSR from old certificate and signing it using new private key Hi, Is it possible to generate a new CSR from old certificate and combine it with the newly generated private key and get it it signed? The use case is, we get the certificates from customers to troubeshoot their issues. As they will not provide the private key, we need to open and check the certificate and create our new CSR with all the fields manually. If it is possible to copy all the fields from customer's certificate and sign it using our private key that would be easy for us. Thanks Kamalraj
