From Majain at verisign.com Wed Jul 1 13:12:56 2015 From: Majain at verisign.com (Jain, Mahendra) Date: Wed, 1 Jul 2015 13:12:56 +0000 Subject: [Pki-users] Configure externally acquired private key and certificate In-Reply-To: References: <558D77EC.8000009@redhat.com> <5592BC36.1010907@redhat.com> <5592D654.7080807@redhat.com> Message-ID: Hi Christina, I followed the steps outlined in https://fedorahosted.org/pki/ticket/456. I was wondering if you could help me with step #3 below about how to specify non-dogtag CA key (test.key) configuration. In other words how to import non-dogtag CA key (test.key) generated in step #2. Here?s what I have done so far: 1. Run "external CA" step one with pkispawn: $ vi step_one.config [DEFAULT] pki_admin_password=password123 pki_backup_password=password123 pki_client_pkcs12_password=password123 pki_ds_password=password123 pki_security_domain_password=password123 pki_backup_keys=True [CA] pki_external=True pki_external_csr_path=/tmp/ca.csr pki_ca_signing_subject_dn=cn=Test Root CA pki_admin_nickname=Test Root CA %(pki_dns_domainname)s pki_admin_subject_dn=cn=CA Admin User,o=%(pki_security_domain_name)s $ pkispawn -s CA -f step_one.config 2. Generate non-dogtag cert using openssl: - Generate private key (test.key) and CSR (test.csr) using OpenSSL utility - Submit CSR to external CA (Ex: Symantec) for signing - Obtain signed cert from external CA - Save CA issued cert and CA root cert in ca.cert and ca_chain.cert files respectively 3. Put the non-dogtag ca b64 cert (ca.cert) as well as the pkcs7 chain (ca_chain.cert) in the proper places: $ vi step_two.config [DEFAULT] pki_admin_password=password123 pki_backup_password=password123 pki_client_pkcs12_password=password123 pki_ds_password=password123 pki_security_domain_password=password123 pki_backup_keys=True [CA] pki_external=True pki_external_ca_cert_chain_path=/tmp/ca_chain.cert pki_external_ca_cert_path=/tmp/ca.cert pki_external_step_two=True pki_ca_signing_subject_dn=cn=Test Root CA pki_admin_nickname=Test Root CA %(pki_dns_domainname)s pki_admin_subject_dn=cn=CA Admin User,o=%(pki_security_domain_name)s 4. Run "external CA" step two with pkispawn: $ pkispawn -s CA -f step_two.config I appreciate your help. Thanks, Mahendra From: , "Jain, Mahendra" > Date: Tuesday, June 30, 2015 at 2:02 PM To: Christina Fu >, "pki-users at redhat.com" > Subject: Re: [Pki-users] Configure externally acquired private key and certificate Hi Christina, Thank you so much. This is exactly I was looking for. Looking at the ticket details, it seems quite old (the last response posted ~ 7 months ago). I?ll give it a try and let you know how it goes. Thanks again, Mahendra From: Christina Fu > Date: Tuesday, June 30, 2015 at 1:48 PM To: "pki-users at redhat.com" > Subject: Re: [Pki-users] Configure externally acquired private key and certificate I think you are talking about this: https://fedorahosted.org/pki/ticket/456 The user have a chance to import own CA certificate with private key Christina On 06/30/2015 09:14 AM, Jain, Mahendra wrote: Hi Christina, Thanks for taking time to respond. We already have clone setup using steps outlined in http://man.sourcentral.org/f18/8+pkispawn and the setup works perfectly fine with no issues. My question is related to Setting up Dogtag using private key and certificate generated via openSSL command separately (on a completely different host from Dogtag). For example, If I delete the complete VM instance where Dogtag is running and reinstall, I could reuse the private key and certificate already generated via openSSL command earlier to setup new Dogtag instance without requiring to generate CSR and get it signed with external CA (Ex: Symantec). Hope this helps. Please let me know if you have any questions. Thanks, Mahendra From: Christina Fu > Date: Tuesday, June 30, 2015 at 11:56 AM To: "pki-users at redhat.com" > Subject: Re: [Pki-users] Configure externally acquired private key and certificate On 06/29/2015 07:32 AM, Jain, Mahendra wrote: Hi Christina, Here?s some detailed information: I?m planning to setup intermediate CA with DogTag and issue SSL server certs. I?m trying 2 options with DogTag setup: Option 1: Installing an externally signed CA I followed the steps outlined in http://man.sourcentral.org/f18/8+pkispawn and this setup works perfectly fine with no issues. This option involves following steps: 1. Generate a certificate signing request (CSR) for the signing certificate in DogTag setup phase 1 2. Submit the CSR to the external CA (Ex: Symantec) 3. Obtain the resulting intermediate certificate and certificate chain 4. Continue with DogTag setup phase 2 Option 2: Installing an externally signed CA (One time setup of keys/CSR) The desired steps are as follows: 1. Generate a certificate signing request (CSR) for the signing certificate using OpenSSL 2. Submit the CSR to the external CA (Ex: Symantec) 3. Obtain the resulting intermediate certificate and certificate chain 4. Store private key and certificate obtained in above steps in secured media so that it can be used later 5. Setup DogTag using the private key (generated in step #1) and intermediate CA certificate (acquired in step #3) The desired expectation in option #2 is to perform step 1-3 below once and then setup DogTag (or recreate VM) as many times I need using private key and certificate obtained earlier. This will prevent us from regenerating CSR and get it signed with external CA (Ex: Symantec). If I read it correctly, you want to set up multiple CA's sharing the same singing cert/keys? Dogtag supports cloning. Did you look into that? Please let me know if you have any questions. Thanks, Mahendra From: , "Jain, Mahendra" > Date: Friday, June 26, 2015 at 12:22 PM To: Christina Fu >, "pki-users at redhat.com" > Subject: Re: [Pki-users] Configure externally acquired private key and certificate Hi Christina, Sorry for the confusion. Let me rephrase the steps below if it is supported: 1. Generate private key and CSR for intermediate CA using openssl 2. Submit the CSR to external CA (Ex: Symantec) for signing 3. Receive the signed certificate from CA 4. Setup DogTag with the private key (generated in step #1) and intermediate CA certificate (acquired in step #3) I?m hoping this approach allows me to perform step 1-3 once and then setup DogTag as many times I need using the existing private key and certificate on any host. Please let me know if you need further clarification. Thanks, Mahendra From: Christina Fu > Date: Friday, June 26, 2015 at 12:03 PM To: "pki-users at redhat.com" > Subject: Re: [Pki-users] Configure externally acquired private key and certificate On 06/25/2015 11:23 AM, Jain, Mahendra wrote: Hi, I?ve DogTag 10.1.2 setup with externally signed CA (using the steps outline in the link below) and the setup works perfectly fine: http://man.sourcentral.org/f18/8+pkispawn I would like to know if DogTag also supports configuring externally acquired private key and certificate. In other words, If I generate the private key and CSR using openssl and submit CSR to CA for certificate. Once the CA issued the certificate, I would like to setup DogTag using the existing private key (created using openssl) and certificate. Hi, I'm sorry I read your questions a few times and I'm not certain what you wish to do. What would you like to use this certificate for? For example, is this an SSL server cert, or CA signing cert? etc. And you mean in another new Dogtag instance, or are you talking about replacing certain system cert of the CA you just set up? Thanks, Mahendra ?This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.? _______________________________________________ Pki-users mailing list Pki-users at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Wed Jul 1 18:32:05 2015 From: cfu at redhat.com (Christina Fu) Date: Wed, 01 Jul 2015 11:32:05 -0700 Subject: [Pki-users] Configure externally acquired private key and certificate In-Reply-To: References: <558D77EC.8000009@redhat.com> <5592BC36.1010907@redhat.com> <5592D654.7080807@redhat.com> Message-ID: <55943225.2080002@redhat.com> I think you can look up openssl the option to create pkcs#12 using cert and key pem's. Once you have the pkcs#12, you can import cert/keys into nssdb using pk12util. You can also look up option in openssl to create pkcs#7 cert chain. Although I am not sure if you can get past "Step 2" of the external CA as it expects to import the CA cert, which you would have already imported via the pk12util from above. It might bomb out. But let's see how far you get. If all it takes is to make pkispawn not to bomb out when trying to import the ca cert, I might be able to move up the ticket priority for you. Christina On 07/01/2015 06:12 AM, Jain, Mahendra wrote: > Hi Christina, > > I followed the steps outlined in https://fedorahosted.org/pki/ticket/456. > I was wondering if you could help me with step #3 below about how to > specify non-dogtag CA key (test.key) configuration. > In other words how to import non-dogtag CA key (test.key) generated in > step #2. > > Here?s what I have done so far: > > *1. Run "external CA" step one with pkispawn:* > > $ vi step_one.config > > > [DEFAULT] > > pki_admin_password=password123 > > pki_backup_password=password123 > > pki_client_pkcs12_password=password123 > > pki_ds_password=password123 > > pki_security_domain_password=password123 > > pki_backup_keys=True > > > [CA] > > pki_external=True > > pki_external_csr_path=/tmp/ca.csr > > pki_ca_signing_subject_dn=cn=Test Root CA > > pki_admin_nickname=Test Root CA %(pki_dns_domainname)s > > pki_admin_subject_dn=cn=CA Admin User,o=%(pki_security_domain_name)s > > > $ pkispawn -s CA -f step_one.config > > > *2. Generate non-dogtag cert using openssl:* > > - Generate private key (*test.key*) and CSR (test.csr) using *OpenSSL* > utility > > - Submit CSR to external CA (Ex: Symantec) for signing > > - Obtain signed cert from external CA > > - Save CA issued cert and CA root cert in ca.cert and ca_chain.cert > files respectively > > > *3. Put the non-dogtag ca b64 cert (ca.cert) as well as the pkcs7 > chain (ca_chain.cert) in the proper places:* > > > $ vi step_two.config > > > [DEFAULT] > > pki_admin_password=password123 > > pki_backup_password=password123 > > pki_client_pkcs12_password=password123 > > pki_ds_password=password123 > > pki_security_domain_password=password123 > > pki_backup_keys=True > > > [CA] > > pki_external=True > > *pki_external_ca_cert_chain_path=/tmp/ca_chain.cert* > > *pki_external_ca_cert_path=/tmp/ca.cert* > > pki_external_step_two=True > > pki_ca_signing_subject_dn=cn=Test Root CA > > pki_admin_nickname=Test Root CA %(pki_dns_domainname)s > > pki_admin_subject_dn=cn=CA Admin User,o=%(pki_security_domain_name)s > > > *4.* *Run "external CA" step two with pkispawn:* > > * > * > > $ pkispawn -s CA -f step_two.config > > > I appreciate your help. > > > Thanks, > Mahendra > > From: , "Jain, Mahendra" > > Date: Tuesday, June 30, 2015 at 2:02 PM > To: Christina Fu >, > "pki-users at redhat.com " > > > Subject: Re: [Pki-users] Configure externally acquired private key and > certificate > > Hi Christina, > > Thank you so much. This is exactly I was looking for. > Looking at the ticket details, it seems quite old (the last response > posted ~ 7 months ago). > > I?ll give it a try and let you know how it goes. > > Thanks again, > Mahendra > > > > > From: Christina Fu > > Date: Tuesday, June 30, 2015 at 1:48 PM > To: "pki-users at redhat.com " > > > Subject: Re: [Pki-users] Configure externally acquired private key and > certificate > > I think you are talking about this: > https://fedorahosted.org/pki/ticket/456 The user have a chance to > import own CA certificate with private key > > Christina > > On 06/30/2015 09:14 AM, Jain, Mahendra wrote: >> Hi Christina, >> >> Thanks for taking time to respond. >> We already have clone setup using steps outlined in >> http://man.sourcentral.org/f18/8+pkispawn and the setup works >> perfectly fine with no issues. >> >> My question is related to Setting up Dogtag using private key >> and certificate generated via openSSL command separately (on a >> completely different host from Dogtag). >> For example, If I delete the complete VM instance where Dogtag is >> running and reinstall, I could reuse the private key and certificate >> already generated via openSSL command earlier to setup new Dogtag >> instance without requiring to generate CSR and get it signed with >> external CA (Ex: Symantec). >> >> Hope this helps. >> >> Please let me know if you have any questions. >> Thanks, >> Mahendra >> >> >> From: Christina Fu > >> Date: Tuesday, June 30, 2015 at 11:56 AM >> To: "pki-users at redhat.com " >> > >> Subject: Re: [Pki-users] Configure externally acquired private key >> and certificate >> >> >> On 06/29/2015 07:32 AM, Jain, Mahendra wrote: >>> Hi Christina, >>> >>> Here?s some detailed information: >>> >>> I?m planning to setup intermediate CA with DogTag and issue SSL >>> server certs. >>> >>> I?m trying 2 options with DogTag setup: >>> >>> *Option 1: Installing an externally signed CA* >>> I followed the steps outlined in >>> http://man.sourcentral.org/f18/8+pkispawn and this setup works >>> perfectly fine with no issues. >>> This option involves following steps: >>> >>> 1. Generate a certificate signing request (CSR) for the signing >>> certificate in DogTag setup phase 1 >>> 2. Submit the CSR to the external CA (Ex: Symantec) >>> 3. Obtain the resulting intermediate certificate and certificate chain >>> 4. Continue with DogTag setup phase 2 >>> >>> *Option 2: Installing an externally signed CA (One time setup of >>> keys/CSR)* >>> >>> The desired steps are as follows: >>> >>> 1. Generate a certificate signing request (CSR) for the signing >>> certificate using *OpenSSL* >>> 2. Submit the CSR to the external CA (Ex: Symantec) >>> 3. Obtain the resulting intermediate certificate and certificate chain >>> 4. Store private key and certificate obtained in above steps in >>> secured media so that it can be used later >>> 5. Setup DogTag using the private key (generated in step #1) and >>> intermediate CA certificate (acquired in step #3) >>> >>> The desired expectation in option #2 is to perform step 1-3 below >>> once and then setup DogTag (or recreate VM) as many times I need >>> using private key and certificate obtained earlier. This will >>> prevent us from regenerating CSR and get it signed with external >>> CA (Ex: Symantec). >> >> If I read it correctly, you want to set up multiple CA's sharing the >> same singing cert/keys? Dogtag supports cloning. Did you look into >> that? >> >>> >>> Please let me know if you have any questions. >>> >>> Thanks, >>> Mahendra >>> >>> >>> From: , "Jain, Mahendra" >> > >>> Date: Friday, June 26, 2015 at 12:22 PM >>> To: Christina Fu >, >>> "pki-users at redhat.com " >>> > >>> Subject: Re: [Pki-users] Configure externally acquired private key >>> and certificate >>> >>> Hi Christina, >>> >>> Sorry for the confusion. Let me rephrase the steps below if it is >>> supported: >>> >>> 1. Generate private key and CSR for intermediate CA using *openssl* >>> 2. Submit the CSR to external CA (Ex: Symantec) for signing >>> 3. Receive the signed certificate from CA >>> 4. Setup DogTag with the private key (generated in step #1) and >>> intermediate CA certificate (acquired in step #3) >>> >>> I?m hoping this approach allows me to perform step 1-3 once and then >>> setup DogTag as many times I need using the existing private key and >>> certificate on any host. >>> >>> Please let me know if you need further clarification. >>> >>> Thanks, >>> Mahendra >>> >>> >>> From: Christina Fu > >>> Date: Friday, June 26, 2015 at 12:03 PM >>> To: "pki-users at redhat.com " >>> > >>> Subject: Re: [Pki-users] Configure externally acquired private key >>> and certificate >>> >>> >>> On 06/25/2015 11:23 AM, Jain, Mahendra wrote: >>>> Hi, >>>> >>>> I?ve DogTag 10.1.2 setup with externally signed CA (using the steps >>>> outline in the link below) and the setup works perfectly fine: >>>> >>>> http://man.sourcentral.org/f18/8+pkispawn >>>> >>>> I would like to know if DogTag also supports configuring externally >>>> acquired private key and certificate. >>>> >>>> In other words, If I generate the private key and CSR using openssl >>>> and submit CSR to CA for certificate. >>>> Once the CA issued the certificate, I would like to setup DogTag >>>> using the existing private key (created using openssl) and certificate. >>> >>> Hi, I'm sorry I read your questions a few times and I'm not certain >>> what you wish to do. What would you like to use this certificate >>> for? For example, is this an SSL server cert, or CA signing cert? >>> etc. And you mean in another new Dogtag instance, or are you talking >>> about replacing certain system cert of the CA you just set up? >>>> >>>> Thanks, >>>> Mahendra >>>> >>>> >>>> ?This message (including any attachments) is intended >>>> only for the use of the individual or entity to which it >>>> is addressed, and may contain information that is >>>> non-public, proprietary, privileged, confidential and >>>> exempt from disclosure under applicable law or may be >>>> constituted as attorney work product. If you are not the >>>> intended recipient, you are hereby notified that any use, >>>> dissemination, distribution, or copying of this >>>> communication is strictly prohibited. If you have >>>> received this message in error, notify sender immediately >>>> and delete this message immediately.? >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pki-users mailing list >>>> Pki-users at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Majain at verisign.com Wed Jul 1 21:01:21 2015 From: Majain at verisign.com (Jain, Mahendra) Date: Wed, 1 Jul 2015 21:01:21 +0000 Subject: [Pki-users] Configure externally acquired private key and certificate In-Reply-To: <55943225.2080002@redhat.com> References: <558D77EC.8000009@redhat.com> <5592BC36.1010907@redhat.com> <5592D654.7080807@redhat.com> <55943225.2080002@redhat.com> Message-ID: Thanks. I will surely give it a try and let you know. - Mahendra From: Christina Fu > Date: Wednesday, July 1, 2015 at 2:32 PM To: "pki-users at redhat.com" > Subject: Re: [Pki-users] Configure externally acquired private key and certificate I think you can look up openssl the option to create pkcs#12 using cert and key pem's. Once you have the pkcs#12, you can import cert/keys into nssdb using pk12util. You can also look up option in openssl to create pkcs#7 cert chain. Although I am not sure if you can get past "Step 2" of the external CA as it expects to import the CA cert, which you would have already imported via the pk12util from above. It might bomb out. But let's see how far you get. If all it takes is to make pkispawn not to bomb out when trying to import the ca cert, I might be able to move up the ticket priority for you. Christina On 07/01/2015 06:12 AM, Jain, Mahendra wrote: Hi Christina, I followed the steps outlined in https://fedorahosted.org/pki/ticket/456. I was wondering if you could help me with step #3 below about how to specify non-dogtag CA key (test.key) configuration. In other words how to import non-dogtag CA key (test.key) generated in step #2. Here?s what I have done so far: 1. Run "external CA" step one with pkispawn: $ vi step_one.config [DEFAULT] pki_admin_password=password123 pki_backup_password=password123 pki_client_pkcs12_password=password123 pki_ds_password=password123 pki_security_domain_password=password123 pki_backup_keys=True [CA] pki_external=True pki_external_csr_path=/tmp/ca.csr pki_ca_signing_subject_dn=cn=Test Root CA pki_admin_nickname=Test Root CA %(pki_dns_domainname)s pki_admin_subject_dn=cn=CA Admin User,o=%(pki_security_domain_name)s $ pkispawn -s CA -f step_one.config 2. Generate non-dogtag cert using openssl: - Generate private key (test.key) and CSR (test.csr) using OpenSSL utility - Submit CSR to external CA (Ex: Symantec) for signing - Obtain signed cert from external CA - Save CA issued cert and CA root cert in ca.cert and ca_chain.cert files respectively 3. Put the non-dogtag ca b64 cert (ca.cert) as well as the pkcs7 chain (ca_chain.cert) in the proper places: $ vi step_two.config [DEFAULT] pki_admin_password=password123 pki_backup_password=password123 pki_client_pkcs12_password=password123 pki_ds_password=password123 pki_security_domain_password=password123 pki_backup_keys=True [CA] pki_external=True pki_external_ca_cert_chain_path=/tmp/ca_chain.cert pki_external_ca_cert_path=/tmp/ca.cert pki_external_step_two=True pki_ca_signing_subject_dn=cn=Test Root CA pki_admin_nickname=Test Root CA %(pki_dns_domainname)s pki_admin_subject_dn=cn=CA Admin User,o=%(pki_security_domain_name)s 4. Run "external CA" step two with pkispawn: $ pkispawn -s CA -f step_two.config I appreciate your help. Thanks, Mahendra From: , "Jain, Mahendra" > Date: Tuesday, June 30, 2015 at 2:02 PM To: Christina Fu >, "pki-users at redhat.com" > Subject: Re: [Pki-users] Configure externally acquired private key and certificate Hi Christina, Thank you so much. This is exactly I was looking for. Looking at the ticket details, it seems quite old (the last response posted ~ 7 months ago). I?ll give it a try and let you know how it goes. Thanks again, Mahendra From: Christina Fu > Date: Tuesday, June 30, 2015 at 1:48 PM To: "pki-users at redhat.com" > Subject: Re: [Pki-users] Configure externally acquired private key and certificate I think you are talking about this: https://fedorahosted.org/pki/ticket/456 The user have a chance to import own CA certificate with private key Christina On 06/30/2015 09:14 AM, Jain, Mahendra wrote: Hi Christina, Thanks for taking time to respond. We already have clone setup using steps outlined in http://man.sourcentral.org/f18/8+pkispawn and the setup works perfectly fine with no issues. My question is related to Setting up Dogtag using private key and certificate generated via openSSL command separately (on a completely different host from Dogtag). For example, If I delete the complete VM instance where Dogtag is running and reinstall, I could reuse the private key and certificate already generated via openSSL command earlier to setup new Dogtag instance without requiring to generate CSR and get it signed with external CA (Ex: Symantec). Hope this helps. Please let me know if you have any questions. Thanks, Mahendra From: Christina Fu > Date: Tuesday, June 30, 2015 at 11:56 AM To: "pki-users at redhat.com" > Subject: Re: [Pki-users] Configure externally acquired private key and certificate On 06/29/2015 07:32 AM, Jain, Mahendra wrote: Hi Christina, Here?s some detailed information: I?m planning to setup intermediate CA with DogTag and issue SSL server certs. I?m trying 2 options with DogTag setup: Option 1: Installing an externally signed CA I followed the steps outlined in http://man.sourcentral.org/f18/8+pkispawn and this setup works perfectly fine with no issues. This option involves following steps: 1. Generate a certificate signing request (CSR) for the signing certificate in DogTag setup phase 1 2. Submit the CSR to the external CA (Ex: Symantec) 3. Obtain the resulting intermediate certificate and certificate chain 4. Continue with DogTag setup phase 2 Option 2: Installing an externally signed CA (One time setup of keys/CSR) The desired steps are as follows: 1. Generate a certificate signing request (CSR) for the signing certificate using OpenSSL 2. Submit the CSR to the external CA (Ex: Symantec) 3. Obtain the resulting intermediate certificate and certificate chain 4. Store private key and certificate obtained in above steps in secured media so that it can be used later 5. Setup DogTag using the private key (generated in step #1) and intermediate CA certificate (acquired in step #3) The desired expectation in option #2 is to perform step 1-3 below once and then setup DogTag (or recreate VM) as many times I need using private key and certificate obtained earlier. This will prevent us from regenerating CSR and get it signed with external CA (Ex: Symantec). If I read it correctly, you want to set up multiple CA's sharing the same singing cert/keys? Dogtag supports cloning. Did you look into that? Please let me know if you have any questions. Thanks, Mahendra From: , "Jain, Mahendra" > Date: Friday, June 26, 2015 at 12:22 PM To: Christina Fu >, "pki-users at redhat.com" > Subject: Re: [Pki-users] Configure externally acquired private key and certificate Hi Christina, Sorry for the confusion. Let me rephrase the steps below if it is supported: 1. Generate private key and CSR for intermediate CA using openssl 2. Submit the CSR to external CA (Ex: Symantec) for signing 3. Receive the signed certificate from CA 4. Setup DogTag with the private key (generated in step #1) and intermediate CA certificate (acquired in step #3) I?m hoping this approach allows me to perform step 1-3 once and then setup DogTag as many times I need using the existing private key and certificate on any host. Please let me know if you need further clarification. Thanks, Mahendra From: Christina Fu > Date: Friday, June 26, 2015 at 12:03 PM To: "pki-users at redhat.com" > Subject: Re: [Pki-users] Configure externally acquired private key and certificate On 06/25/2015 11:23 AM, Jain, Mahendra wrote: Hi, I?ve DogTag 10.1.2 setup with externally signed CA (using the steps outline in the link below) and the setup works perfectly fine: http://man.sourcentral.org/f18/8+pkispawn I would like to know if DogTag also supports configuring externally acquired private key and certificate. In other words, If I generate the private key and CSR using openssl and submit CSR to CA for certificate. Once the CA issued the certificate, I would like to setup DogTag using the existing private key (created using openssl) and certificate. Hi, I'm sorry I read your questions a few times and I'm not certain what you wish to do. What would you like to use this certificate for? For example, is this an SSL server cert, or CA signing cert? etc. And you mean in another new Dogtag instance, or are you talking about replacing certain system cert of the CA you just set up? Thanks, Mahendra ?This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.? _______________________________________________ Pki-users mailing list Pki-users at redhat.comhttps://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.w.jung at gmail.com Thu Jul 9 11:44:17 2015 From: alexander.w.jung at gmail.com (Alexander Jung) Date: Thu, 9 Jul 2015 13:44:17 +0200 Subject: [Pki-users] partition dogtag data in the ldap server? Message-ID: Hi, we have a rather large dogtag install here and the ldap-info is getting hard to handle (right now in the ~75Gb range). Are there any recomended ways to partition the data ? I am thinking of migrating all expired and revoked certificates to a chainend ldap-instance and keep only the "valid" certificates data in direct access to the CA instances. The migration from the "valid" partition to the "expired" partition will have to be done outside of dogtag and the 389ds-ldaps, probably by a script at night (it probably could be integrated into the expire runs the dogtag does, although) Has a thing like this been done yet? What were the experiences ? What sould I look out for ? Mit freundlichen Gr??en, Alexander Jung -------------- next part -------------- An HTML attachment was scrubbed... URL: From tangoxix at gmail.com Mon Jul 13 20:53:56 2015 From: tangoxix at gmail.com (Ben Peck) Date: Mon, 13 Jul 2015 15:53:56 -0500 Subject: [Pki-users] How to install RA on DogTag 10? Message-ID: I'm running Fedora 21 with Dogtag 10.2.1-3 and trying to get the Registration Authority subsystem to install to enable SCEP ultimately. I installed pki-ra, but when I run "pkispawn -s RA" I get the following: Traceback (most recent call last): File "/usr/sbin/pkispawn", line 579, in main(sys.argv) File "/usr/sbin/pkispawn", line 143, in main parser.init_config() File "/usr/lib/python2.7/site-packages/pki/server/ deployment/pkiparser.py", line 192, in init_config 'pki_instance_name': default_instance_name, UnboundLocalError: local variable 'default_instance_name' referenced before assignment Can anyone point me in the right direction concerning SCEP and DogTag 10? Is there some updated documentation on this somewhere I'm missing? Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From Majain at verisign.com Mon Jul 20 20:33:28 2015 From: Majain at verisign.com (Jain, Mahendra) Date: Mon, 20 Jul 2015 20:33:28 +0000 Subject: [Pki-users] Dogtag : Configuring default OCSP URI Message-ID: Hi, I'm running Fedora 21 with Dogtag 10.2.1-3 and would like to configure default OCSP URI that appears in the certificate. The certificate issued by Dogtag includes following OCSP details: Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1 Critical: no Access Description: Method #0: ocsp Location #0: URIName: http://server.example.com:8080/ca/ocsp I would like to update the above URIName (via configuration) to something like http://ocsp.example.com:8080/ca/ocsp. Please advice. Thanks, Mahendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From Majain at verisign.com Mon Jul 20 21:46:56 2015 From: Majain at verisign.com (Jain, Mahendra) Date: Mon, 20 Jul 2015 21:46:56 +0000 Subject: [Pki-users] Dogtag : Configuring default OCSP URI In-Reply-To: References: Message-ID: Never mind. Got it working after updating the following entry in the caServerCert.cfg: policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ocsp.example.com:8080/ca/ocsp From: , "Jain, Mahendra" > Date: Monday, July 20, 2015 at 4:33 PM To: "pki-users at redhat.com" > Subject: [Pki-users] Dogtag : Configuring default OCSP URI Hi, I'm running Fedora 21 with Dogtag 10.2.1-3 and would like to configure default OCSP URI that appears in the certificate. The certificate issued by Dogtag includes following OCSP details: Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1 Critical: no Access Description: Method #0: ocsp Location #0: URIName: http://server.example.com:8080/ca/ocsp I would like to update the above URIName (via configuration) to something like http://ocsp.example.com:8080/ca/ocsp. Please advice. Thanks, Mahendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsirrine at redhat.com Wed Jul 22 18:35:08 2015 From: dsirrine at redhat.com (Dave Sirrine) Date: Wed, 22 Jul 2015 14:35:08 -0400 (EDT) Subject: [Pki-users] partition dogtag data in the ldap server? In-Reply-To: References: Message-ID: <1534087380.1506554.1437590108132.JavaMail.zimbra@redhat.com> Alexander, Can you define "hard to handle"? What version of Dogtag are you using? Are you running into performance degradation? Unfortunately, it likely won't be too easy to segregate this data. In dogtag 10.2 there should be a scheduled job that regularly runs through and removes all expired certs: jobsScheduler.impl.UnpublishExpiredJob.class=com.netscape.cms.jobs.UnpublishExpiredJob jobsScheduler.job.unpublishExpiredCerts.cron=0 0 * * 6 Thanks in advance. -- Dave ----- Original Message ----- > From: "Alexander Jung" > To: "pki-users at redhat.com" > Sent: Thursday, July 9, 2015 7:44:17 AM > Subject: [Pki-users] partition dogtag data in the ldap server? > Hi, > we have a rather large dogtag install here and the ldap-info is getting hard > to handle (right now in the ~75Gb range). > Are there any recomended ways to partition the data ? I am thinking of > migrating all expired and revoked certificates to a chainend ldap-instance > and keep only the "valid" certificates data in direct access to the CA > instances. > The migration from the "valid" partition to the "expired" partition will have > to be done outside of dogtag and the 389ds-ldaps, probably by a script at > night (it probably could be integrated into the expire runs the dogtag does, > although) > Has a thing like this been done yet? What were the experiences ? What sould I > look out for ? > Mit freundlichen Gr??en, > Alexander Jung > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsirrine at redhat.com Wed Jul 22 19:16:17 2015 From: dsirrine at redhat.com (Dave Sirrine) Date: Wed, 22 Jul 2015 15:16:17 -0400 (EDT) Subject: [Pki-users] How to install RA on DogTag 10? In-Reply-To: References: Message-ID: <1353572365.1517942.1437592577488.JavaMail.zimbra@redhat.com> Ben, Looks like this has already been answered here: https://www.redhat.com/archives/pki-users/2014-June/msg00004.html . pkispawn only works for CA, KRA, TKS, TPS, and OCSP. Here's the meat of that email thread: ~~~ > In order to install a native Apache-based RA (or a legacy TPS) instance, you > must still use the 'pkicreate' installer, and configure the instance using a > browser with the GUI interface or construct the proper arguments to the > 'pkisilent' configuration tool. ~~~ There is a trac ticket for references to RA to be removed from pkispawn. Hope this helps! -- Dave ----- Original Message ----- > From: "Ben Peck" > To: pki-users at redhat.com > Sent: Monday, July 13, 2015 4:53:56 PM > Subject: [Pki-users] How to install RA on DogTag 10? > I'm running Fedora 21 with Dogtag 10.2.1-3 and trying to get the Registration > Authority subsystem to install to enable SCEP ultimately. > I installed pki-ra, but when I run "pkispawn -s RA" I get the following: > Traceback (most recent call last): > File "/usr/sbin/pkispawn", line 579, in > main(sys.argv) > File "/usr/sbin/pkispawn", line 143, in main > parser.init_config() > File "/usr/lib/python2.7/site- packages/pki/server/ deployment/pkiparser.py", > line 192, in init_config > 'pki_instance_name': default_instance_name, > UnboundLocalError: local variable 'default_instance_name' referenced > before assignment > Can anyone point me in the right direction concerning SCEP and DogTag 10? Is > there some updated documentation on this somewhere I'm missing? > Thanks, > Ben > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Wed Jul 22 20:43:15 2015 From: cfu at redhat.com (Christina Fu) Date: Wed, 22 Jul 2015 13:43:15 -0700 Subject: [Pki-users] partition dogtag data in the ldap server? In-Reply-To: <1534087380.1506554.1437590108132.JavaMail.zimbra@redhat.com> References: <1534087380.1506554.1437590108132.JavaMail.zimbra@redhat.com> Message-ID: <55B00063.2040703@redhat.com> Thank you Dave for bringing this email to my attention...somehow it got slipped by me. I just want to point out that if you do choose to "remove" certs from the internal ldap repository, please do not remove any certs that are revoked but not yet expired. Doing so will cause your CRL generation to miss the revoked certificates, and render them valid when checked upon by clients. It would be a big security violation of PKI. regards, Christina On 07/22/2015 11:35 AM, Dave Sirrine wrote: > Alexander, > > Can you define "hard to handle"? What version of Dogtag are you using? > Are you running into performance degradation? Unfortunately, it likely > won't be too easy to segregate this data. In dogtag 10.2 there should > be a scheduled job that regularly runs through and removes all expired > certs: > > jobsScheduler.impl.UnpublishExpiredJob.class=com.netscape.cms.jobs.UnpublishExpiredJob > jobsScheduler.job.unpublishExpiredCerts.cron=0 0 * * 6 > > Thanks in advance. > > -- Dave > > ------------------------------------------------------------------------ > > *From: *"Alexander Jung" > *To: *"pki-users at redhat.com" > *Sent: *Thursday, July 9, 2015 7:44:17 AM > *Subject: *[Pki-users] partition dogtag data in the ldap server? > > Hi, > > we have a rather large dogtag install here and the ldap-info is > getting hard to handle (right now in the ~75Gb range). > > Are there any recomended ways to partition the data ? I am > thinking of migrating all expired and revoked certificates to a > chainend ldap-instance and keep only the "valid" certificates data > in direct access to the CA instances. > > The migration from the "valid" partition to the "expired" > partition will have to be done outside of dogtag and the > 389ds-ldaps, probably by a script at night (it probably could be > integrated into the expire runs the dogtag does, although) > > Has a thing like this been done yet? What were the experiences ? > What sould I look out for ? > > Mit freundlichen Gr??en, > > Alexander Jung > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users > > > > > _______________________________________________ > Pki-users mailing list > Pki-users at redhat.com > https://www.redhat.com/mailman/listinfo/pki-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.w.jung at gmail.com Fri Jul 24 07:07:55 2015 From: alexander.w.jung at gmail.com (Alexander Jung) Date: Fri, 24 Jul 2015 09:07:55 +0200 Subject: [Pki-users] partition dogtag data in the ldap server? In-Reply-To: <55B00063.2040703@redhat.com> References: <1534087380.1506554.1437590108132.JavaMail.zimbra@redhat.com> <55B00063.2040703@redhat.com> Message-ID: 2015-07-22 22:43 GMT+02:00 Christina Fu : > Thank you Dave for bringing this email to my attention...somehow it got > slipped by me. > > I just want to point out that if you do choose to "remove" certs from the > internal ldap repository, please do not remove any certs that are revoked > but not yet expired. Doing so will cause your CRL generation to miss the > revoked certificates, and render them valid when checked upon by clients. > It would be a big security violation of PKI. > Yes, I am planing to move only the expired (or revoked-expired certs). While we do not really use the CRL any more (OCSP is the thing nowadays :-), we keep it for compatibility... Mit freundlichen Gr??en, Alexander Jung -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.w.jung at gmail.com Fri Jul 24 07:13:30 2015 From: alexander.w.jung at gmail.com (Alexander Jung) Date: Fri, 24 Jul 2015 09:13:30 +0200 Subject: [Pki-users] partition dogtag data in the ldap server? In-Reply-To: <1534087380.1506554.1437590108132.JavaMail.zimbra@redhat.com> References: <1534087380.1506554.1437590108132.JavaMail.zimbra@redhat.com> Message-ID: 2015-07-22 20:35 GMT+02:00 Dave Sirrine : > Alexander, > > Can you define "hard to handle"? > Hard to handle is a stock of over 4 Million certificates, of which about 10% are valid ones. The ldap database is with the indexes in the 100Gb range, LDIF Backups take more than three hours and might fail if too many changes occur during the night time we run them. > What version of Dogtag are you using? > 10.1. something (= the version that came out in February this year, but the history in that ldap is migrated since around 2007) > Are you running into performance degradation? > Yes, we had a perfomenace degradation , but that was a lookup error in the code (I really have to get around to send our fixes here back to you) Unfortunately, it likely won't be too easy to segregate this data. In > dogtag 10.2 there should be a scheduled job that regularly runs through and > removes all expired certs: > > > jobsScheduler.impl.UnpublishExpiredJob.class=com.netscape.cms.jobs.UnpublishExpiredJob > jobsScheduler.job.unpublishExpiredCerts.cron=0 0 * * 6 > Thanks for the pointer, I'll try to attach to this one. Mit freundlichen Gr??en, Alexander Jung -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfu at redhat.com Fri Jul 24 16:08:35 2015 From: cfu at redhat.com (Christina Fu) Date: Fri, 24 Jul 2015 09:08:35 -0700 Subject: [Pki-users] partition dogtag data in the ldap server? In-Reply-To: References: <1534087380.1506554.1437590108132.JavaMail.zimbra@redhat.com> <55B00063.2040703@redhat.com> Message-ID: <55B26303.9040408@redhat.com> On 07/24/2015 12:07 AM, Alexander Jung wrote: > > 2015-07-22 22:43 GMT+02:00 Christina Fu >: > > Thank you Dave for bringing this email to my attention...somehow > it got slipped by me. > > I just want to point out that if you do choose to "remove" certs > from the internal ldap repository, please do not remove any certs > that are revoked but not yet expired. Doing so will cause your > CRL generation to miss the revoked certificates, and render them > valid when checked upon by clients. It would be a big security > violation of PKI. > > > Yes, I am planing to move only the expired (or revoked-expired certs). > While we do not really use the CRL any more (OCSP is the thing > nowadays :-), we keep it for compatibility... > Good to know. Though as far as Dogtag goes, OCSP gets its CRL from the CA, where CA generates its CRL from the certs in its internal ldap db. CA needs to keep its CRL accurate and updated for the whole PKI to work properly. > Mit freundlichen Gr??en, > > Alexander Jung > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmagne at redhat.com Fri Jul 31 21:01:17 2015 From: jmagne at redhat.com (John Magne) Date: Fri, 31 Jul 2015 17:01:17 -0400 (EDT) Subject: [Pki-users] [pki-devel][PATCH] 0046-Firefox-warning.patch In-Reply-To: <1863165240.3716386.1438376444039.JavaMail.zimbra@redhat.com> Message-ID: <768368813.3716537.1438376477951.JavaMail.zimbra@redhat.com> Firefox warning Ticket #1523 Move the dire warning about the crypto object to sections where it applies. Also slightly changed the message due to context. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0046-Firefox-warning.patch Type: text/x-patch Size: 3817 bytes Desc: not available URL: