[Fedora-directory-users] Proper way to generate a server certificate.

Wed Jan 28 23:02:41 UTC 2009

Chavez, James R. wrote:
> Rich,
> Thank you again.
> The GUI console will not allow me to get past the 3rd screen where it
> asks for a password to the internal software store..I enter the correct
> password and it just sits there. I know the pass is correct because from
> the command line the same pass works to access the store.
> It will not go past. I have done this on various machines and it is the
> same result. Is there some kind of bug or needed software I need to have
> this function. All boxes are running.
>   
Try running fedora-idm-console -D 9 -f console.log
email me the console.log
also check the admin server error log - /var/log/dirsrv/admin-serv/error
> Fedora 9 and 
>
> fedora-ds 
> version 1.1.1
> Release 3.fc9 
>
>
> Also, I sent a cert request (CSR) to the needed Novell CA and had them
> sign it and return it. 
> I successfully imported it.
> The server cert I imported shows as having a broken chain on the
> certification path tab. And issued by null.
> I am assuming this is due to not having imported the CA cert that issued
> this cert yet..Is that a valid assumption?
>   
Yes.
> Do I need the CA certificate in order to properly use this server cert
> that was generated?
>   
Yes.
>
> Thank you
> James
>
>
>
> -----Original Message-----
> From: Rich Megginson [mailto:rmeggins at redhat.com] 
> Sent: Wednesday, January 28, 2009 3:21 PM
> To: Chavez, James R.
> Cc: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Proper way to generate a server
> certificate.
>
> Chavez, James R. wrote:
>   
>> Mr. Rich, you responded!!
>> Thank you
>>
>> Thing is I generate a certificate request but am having issues 
>> importing it...
>> I generate a key and cert with.. 
>> "openssl genrsa -des3 -out server.key 2048" for the key "openssl req 
>> -new -key server.key -out server.csr"
>> I send it to the Novell Admin and sends back a server.b64 file.
>> I try and import it through the gui as a server cert and it fails 
>> saying that.
>>
>> " Either the certificate is for another server or the certificate was 
>> not requested using this server and the selected security device 
>> "internal (software)""
>>
>> I can import it as a CA cert but it shows as a broken chain and it is 
>> supposed to be server cert anyway.
>>
>> Any ideas on how to properly import this base 64 signed cert?
>> Perhaps certutil or openssl commands?
>>   
>>     
> If you are going to generate a server cert request, and you are going to
> use the GUI, you should just use the GUI to generate the server cert
> request.  Then you can submit that request to your CA and have it
> generate the server cert, then you can use the GUI again to install your
> new server cert.  You will also need to install the CA cert using the
> Fedora DS console GUI.
>   
>> Thank You
>> James
>>
>> Openssl
>> -----Original Message-----
>> From: Rich Megginson [mailto:rmeggins at redhat.com]
>> Sent: Wednesday, January 28, 2009 1:48 PM
>> To: Chavez, James R.; General discussion list for the Fedora Directory
>>     
>
>   
>> server project.
>> Subject: Re: [Fedora-directory-users] Proper way to generate a server 
>> certificate.
>>
>> James Chavez wrote:
>>   
>>     
>>> Hello List,
>>>
>>> I am trying to setup SSL between an AD or edir box and my FDS box. 
>>> I want to generate a server cert for the AD or edir box and import it
>>>       
>
>   
>>> into edir/AD and import the CA cert into AD/edir as well.
>>>
>>> What commands do i use to accomplish this.
>>> Also what format does the cert need to be to successfully import into
>>>       
>
>   
>>> AD or edir.
>>>
>>> I have generated a self signed CA cert named "FDS CA"
>>> exported with 
>>> certutil -L -d . -n "FDS CA" -a > ca.asc   and
>>> certutil -L -d . -n "FDS CA" -r > ca.der
>>>
>>>
>>>
>>> I have generated a server cert for the AD/edir box with
>>>
>>>  certutil -S -n "server-Cert" -s "cn=host.example.com" -c "FDS CA" -t
>>>       
>
>   
>>> "u,u,u" -m 3002 -v 120 -d . -z ./noise.txt -f ./pwdfile.txt
>>>
>>> And exported it with..
>>> pk12util -d . -o /tmp/server-cert.p12 -n "server-Cert"
>>>
>>> I then send the CA cert in ascii and .der format along with the
>>> server-cert.p12 to the admin but he gets errors below trying to 
>>> import
>>>     
>>>       
>>   
>>     
>>> into edir.
>>> Need help on this one please. 
>>> ..
>>>
>>> -1240 FFFFFB28 PKI E PARSE CERTIFICATE
>>>   
>>>     
>>>       
>> I'm not sure, but why not just use Novell Certificate Server to 
>> generate all of your server certs?
>>   
>>     
>>> Source
>>>
>>> Novell(r) Certificate Server
>>>
>>> Explanation
>>>
>>> Novell Certificate Server was unable to parse a certificate that has 
>>> been stored or is being stored.
>>>
>>> Possible Cause
>>>
>>> The user attempted to store a certificate or a certificate chain with
>>>       
>
>   
>>> an invalid encoding into a Server Certificate object. The certificate
>>>       
>
>   
>>> or certificate chain obtained from the Certificate Authority is
>>>     
>>>       
>> invalid.
>>   
>>     
>>> Action
>>>
>>> Perform the following operations:
>>>
>>>     * Contact the Certificate Authority that issued the server 
>>> certificate to obtain the Certificate Authority's certificate.
>>>     * Using ConsoleOne(r), view the Server Certificate object. Click 
>>> Import.
>>>     * Import the Certificate Authority's certificate as the trusted 
>>> root.
>>>     * Import the server's certificate as the object certificate.
>>>
>>> If the problem persists, contact the Certificate Authority.
>>>
>>>
>>> Any body out there can help out please.
>>>
>>> Thanks
>>> James
>>>
>>> CONFIDENTIALITY
>>> This e-mail message and any attachments thereto, is intended only for
>>>     
>>>       
>> use by the addressee(s) named herein and may contain legally 
>> privileged and/or confidential information. If you are not the 
>> intended recipient of this e-mail message, you are hereby notified 
>> that any dissemination, distribution or copying of this e-mail 
>> message, and any attachments thereto, is strictly prohibited.  If you 
>> have received this e-mail message in error, please immediately notify 
>> the sender and permanently delete the original and any copies of this
>>     
> email and any prints thereof.
>   
>>   
>>     
>>> ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL
>>>     
>>>       
>> IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the 
>> Uniform Electronic Transactions Act or the applicability of any other 
>> law of similar substance and effect, absent an express statement to 
>> the contrary hereinabove, this e-mail message its contents, and any 
>> attachments hereto are not intended to represent an offer or 
>> acceptance to enter into a contract and are not otherwise intended to 
>> bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries),
>>     
>
>   
>> or any other person or entity.
>>   
>>     
>>> --
>>> Fedora-directory-users mailing list
>>> Fedora-directory-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>   
>>>     
>>>       
>> CONFIDENTIALITY
>> This e-mail message and any attachments thereto, is intended only for
>>     
> use by the addressee(s) named herein and may contain legally privileged
> and/or confidential information. If you are not the intended recipient
> of this e-mail message, you are hereby notified that any dissemination,
> distribution or copying of this e-mail message, and any attachments
> thereto, is strictly prohibited.  If you have received this e-mail
> message in error, please immediately notify the sender and permanently
> delete the original and any copies of this email and any prints thereof.
>   
>> ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL
>>     
> IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the
> Uniform Electronic Transactions Act or the applicability of any other
> law of similar substance and effect, absent an express statement to the
> contrary hereinabove, this e-mail message its contents, and any
> attachments hereto are not intended to represent an offer or acceptance
> to enter into a contract and are not otherwise intended to bind the
> sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any
> other person or entity.
>   
>>   
>>     
>
>
> CONFIDENTIALITY
> This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited.  If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof.
> ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING.  Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity.
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20090128/d2395032/attachment.bin>