FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 09-09-2010, 02:45 AM
John Mancuso
 
Default SSL Cert Issue

Two questions:

1. I have generated self-signed ssl/ca certs trying both the
"certutil" method from the redhat doc and also the standard "openssl
x509 req -new" method. After installing the certs and enabling secure
ldaps replication both result in

slapi_ldap_bind - Error: could not send bind request for id
[cn=replication manager,cn=config] mech [SIMPLE]: error 81 (Can't
contact LDAP server) -8172 (Peer's certificate issuer has been marked
as not trusted by the user.) 11 (Resource temporarily unavailable)

Is there a known issue with self-signed certs?

2. If there is an issue with the above, we may end up purchasing a
wildcard cert for replicating across subdomains. I know in the HTML
world some web browsers complain about ssl wildcard certs across
subdomains. Any possible issues with this approach?

ldaps://supplier_ldap.mycompany.com----> ldaps://consumer_ldap.dev.mycompany.com
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-09-2010, 02:47 AM
brandon
 
Default SSL Cert Issue

On 09/08/2010 08:45 PM, John Mancuso wrote:
> Two questions:
>
> 1. I have generated self-signed ssl/ca certs trying both the
> "certutil" method from the redhat doc and also the standard "openssl
> x509 req -new" method. After installing the certs and enabling secure
> ldaps replication both result in
>
> slapi_ldap_bind - Error: could not send bind request for id
> [cn=replication manager,cn=config] mech [SIMPLE]: error 81 (Can't
> contact LDAP server) -8172 (Peer's certificate issuer has been marked
> as not trusted by the user.) 11 (Resource temporarily unavailable)
>
> Is there a known issue with self-signed certs?
>
> 2. If there is an issue with the above, we may end up purchasing a
> wildcard cert for replicating across subdomains. I know in the HTML
> world some web browsers complain about ssl wildcard certs across
> subdomains. Any possible issues with this approach?
>
> ldaps://supplier_ldap.mycompany.com----> ldaps://consumer_ldap.dev.mycompany.com
>


You need to create your own CA Cert, sign your cert with that CA Cert,
and import the CA cert into the certutil store.

You also want to put the CA public cert into /etc/openldap/certs so the
openldap tools will use it.

There are a few guides on the internet for creating your own CA. I know
Fedora 13 comes with its own CA tool. I personally use tinyca.

-B
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-09-2010, 02:49 AM
Rob Crittenden
 
Default SSL Cert Issue

John Mancuso wrote:
> Two questions:
>
> 1. I have generated self-signed ssl/ca certs trying both the
> "certutil" method from the redhat doc and also the standard "openssl
> x509 req -new" method. After installing the certs and enabling secure
> ldaps replication both result in
>
> slapi_ldap_bind - Error: could not send bind request for id
> [cn=replication manager,cn=config] mech [SIMPLE]: error 81 (Can't
> contact LDAP server) -8172 (Peer's certificate issuer has been marked
> as not trusted by the user.) 11 (Resource temporarily unavailable)
>
> Is there a known issue with self-signed certs?

No, they work fine. Did you add the CA certificate that signed the
server certificate as well?

You can verify that the certificate is ok on the server with:

certutil -V -u V -d /etc/dirsrv/slapd-<YOUR_INSTANCE>

You are probably just missing the CA certificate. If you have it in PEM
format you can add it via the command-line with:

certutil -A -d /etc/dirsrv/slapd-<YOUR_INSTANCE> -n 'Your CA' -t CT,, -a
< /path/to/ca.pem

The 'Your CA' here is the nickname of the CA certificate. It is how it
will appear in the DS console and using certutil -L. Pick something
meaningful to you.

> 2. If there is an issue with the above, we may end up purchasing a
> wildcard cert for replicating across subdomains. I know in the HTML
> world some web browsers complain about ssl wildcard certs across
> subdomains. Any possible issues with this approach?
>
> ldaps://supplier_ldap.mycompany.com----> ldaps://consumer_ldap.dev.mycompany.com

A wildcard cert will work but its probably overkill to buy one just for
this purpose. self-signed certificates will work fine.

rob
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-09-2010, 04:20 AM
John Mancuso
 
Default SSL Cert Issue

I followed the exact procedure below numerous times with the same
frustrating error:

http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Managing_SSL-Using_certutil.html#certutil-procedure

!481 $ openssl verify cacert_core.asc
cacert_core.asc: /DC=tv/DC=freewheel/CN=CA cert
error 18 at 0 depth lookup:self signed certificate
OK

!482 $ openssl verify cacert_PEKdev020.asc
cacert_PEKdev020.asc: /DC=tv/DC=freewheel/CN=CA cert
error 18 at 0 depth lookup:self signed certificate
OK

!474 $ certutil -V -u V -d . -n "Core CA certificate"
certutil: certificate is valid

!476 $ certutil -V -u V -d . -n "Core Server-Cert"
certutil: certificate is valid

I also imported the consumers CA cert into the supplier ... this is
correct? I tried only importing the suppliers CA cert before with the
same issue (trying everything here!)

This looks strange though (why the duplicate cert):

!478 $ certutil -d . -L

Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Core Server-Cert u,u,u
Core CA certificate CTu,u,u
Core CA certificate CT,,



On Wed, Sep 8, 2010 at 10:49 PM, Rob Crittenden <rcritten@redhat.com> wrote:
> John Mancuso wrote:
>>
>> Two questions:
>>
>> 1. I have generated self-signed ssl/ca certs trying both the
>> "certutil" method from the redhat doc and also the standard "openssl
>> x509 req -new" method. After installing the certs and enabling secure
>> ldaps replication both result in
>>
>> slapi_ldap_bind - Error: could not send bind request for id
>> [cn=replication manager,cn=config] mech [SIMPLE]: error 81 (Can't
>> contact LDAP server) -8172 (Peer's certificate issuer has been marked
>> as not trusted by the user.) 11 (Resource temporarily unavailable)
>>
>> Is there a known issue with self-signed certs?
>
> No, they work fine. Did you add the CA certificate that signed the server
> certificate as well?
>
> You can verify that the certificate is ok on the server with:
>
> certutil -V -u V -d /etc/dirsrv/slapd-<YOUR_INSTANCE>
>
> You are probably just missing the CA certificate. If you have it in PEM
> format you can add it via the command-line with:
>
> certutil -A -d /etc/dirsrv/slapd-<YOUR_INSTANCE> -n 'Your CA' -t CT,, -a <
> /path/to/ca.pem
>
> The 'Your CA' here is the nickname of the CA certificate. It is how it will
> appear in the DS console and using certutil -L. Pick something meaningful to
> you.
>
>> 2. If there is an issue with the above, we may end up purchasing a
>> wildcard cert for replicating across subdomains. I know in the HTML
>> world some web browsers complain about ssl wildcard certs across
>> subdomains. Any possible issues with this approach?
>>
>> ldaps://supplier_ldap.mycompany.com---->
>> *ldaps://consumer_ldap.dev.mycompany.com
>
> A wildcard cert will work but its probably overkill to buy one just for this
> purpose. self-signed certificates will work fine.
>
> rob
>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-09-2010, 01:02 PM
Rob Crittenden
 
Default SSL Cert Issue

John Mancuso wrote:
> I followed the exact procedure below numerous times with the same
> frustrating error:
>
> http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Managing_SSL-Using_certutil.html#certutil-procedure
>
> !481 $ openssl verify cacert_core.asc
> cacert_core.asc: /DC=tv/DC=freewheel/CN=CA cert
> error 18 at 0 depth lookup:self signed certificate
> OK
>
> !482 $ openssl verify cacert_PEKdev020.asc
> cacert_PEKdev020.asc: /DC=tv/DC=freewheel/CN=CA cert
> error 18 at 0 depth lookup:self signed certificate
> OK
>
> !474 $ certutil -V -u V -d . -n "Core CA certificate"
> certutil: certificate is valid
>
> !476 $ certutil -V -u V -d . -n "Core Server-Cert"
> certutil: certificate is valid
>
> I also imported the consumers CA cert into the supplier ... this is
> correct? I tried only importing the suppliers CA cert before with the
> same issue (trying everything here!)
>
> This looks strange though (why the duplicate cert):
>
> !478 $ certutil -d . -L
>
> Certificate Nickname Trust Attributes
> SSL,S/MIME,JAR/XPI
> Core Server-Cert u,u,u
> Core CA certificate CTu,u,u
> Core CA certificate CT,,
>

Ok, I think I know what you're seeing. Did you do the same procedure on
both the master and the replica?

If you did then you created two separate CAs that know nothing about
each other and don't trust one another.

You probably just want one CA in this case so I'd just pick either the
master or replica and issue another server certificate from it:

certutil -S -n "Replica-Cert" -s "cn=FQDN" -c "CA certificate" -t
"u,u,u" -m 1001 -v 120 -d . -k rsa -g 1024 -f /tmp/pwdfile

Then use pk12util to create a PKCS#12 file containing the cert and
private key:

pk12util -o replica.p12 -d . -n Replica-Cert

Ship this over to the replica and import it with:

pk12util -i replica.p12 -d .

The CA cert should be included in the PKCS#12 file but if it isn't
you'll need to grab it from the master and install it on the replica.

rob

>
>
> On Wed, Sep 8, 2010 at 10:49 PM, Rob Crittenden<rcritten@redhat.com> wrote:
>> John Mancuso wrote:
>>>
>>> Two questions:
>>>
>>> 1. I have generated self-signed ssl/ca certs trying both the
>>> "certutil" method from the redhat doc and also the standard "openssl
>>> x509 req -new" method. After installing the certs and enabling secure
>>> ldaps replication both result in
>>>
>>> slapi_ldap_bind - Error: could not send bind request for id
>>> [cn=replication manager,cn=config] mech [SIMPLE]: error 81 (Can't
>>> contact LDAP server) -8172 (Peer's certificate issuer has been marked
>>> as not trusted by the user.) 11 (Resource temporarily unavailable)
>>>
>>> Is there a known issue with self-signed certs?
>>
>> No, they work fine. Did you add the CA certificate that signed the server
>> certificate as well?
>>
>> You can verify that the certificate is ok on the server with:
>>
>> certutil -V -u V -d /etc/dirsrv/slapd-<YOUR_INSTANCE>
>>
>> You are probably just missing the CA certificate. If you have it in PEM
>> format you can add it via the command-line with:
>>
>> certutil -A -d /etc/dirsrv/slapd-<YOUR_INSTANCE> -n 'Your CA' -t CT,, -a<
>> /path/to/ca.pem
>>
>> The 'Your CA' here is the nickname of the CA certificate. It is how it will
>> appear in the DS console and using certutil -L. Pick something meaningful to
>> you.
>>
>>> 2. If there is an issue with the above, we may end up purchasing a
>>> wildcard cert for replicating across subdomains. I know in the HTML
>>> world some web browsers complain about ssl wildcard certs across
>>> subdomains. Any possible issues with this approach?
>>>
>>> ldaps://supplier_ldap.mycompany.com---->
>>> ldaps://consumer_ldap.dev.mycompany.com
>>
>> A wildcard cert will work but its probably overkill to buy one just for this
>> purpose. self-signed certificates will work fine.
>>
>> rob
>>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-09-2010, 08:28 PM
John Mancuso
 
Default SSL Cert Issue

That's what it was! thanks. Unfortunately going across subdomains was a no go :

-12276 (Unable to communicate securely with peer: requested domain
name does not match the server's certificate.

I tried to generate a self signed wildcard (cn=*.mycompany.com) but no
luck there. Thanks anyways!

On Thu, Sep 9, 2010 at 9:02 AM, Rob Crittenden <rcritten@redhat.com> wrote:
> John Mancuso wrote:
>>
>> I followed the exact procedure below numerous times with the same
>> frustrating error:
>>
>>
>> http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Managing_SSL-Using_certutil.html#certutil-procedure
>>
>> !481 $ openssl verify cacert_core.asc
>> cacert_core.asc: /DC=tv/DC=freewheel/CN=CA cert
>> error 18 at 0 depth lookup:self signed certificate
>> OK
>>
>> !482 $ openssl verify cacert_PEKdev020.asc
>> cacert_PEKdev020.asc: /DC=tv/DC=freewheel/CN=CA cert
>> error 18 at 0 depth lookup:self signed certificate
>> OK
>>
>> !474 $ certutil -V -u V -d . -n "Core CA certificate"
>> certutil: certificate is valid
>>
>> !476 $ certutil -V -u V -d . -n "Core Server-Cert"
>> certutil: certificate is valid
>>
>> I also imported the consumers CA cert into the supplier ... this is
>> correct? I tried only importing the suppliers CA cert before with the
>> same issue (trying everything here!)
>>
>> This looks strange though (why the duplicate cert):
>>
>> !478 $ certutil -d . -L
>>
>> Certificate Nickname * * * * * * * * * * * * * * * * * * * * Trust
>> Attributes
>>
>> *SSL,S/MIME,JAR/XPI
>> Core Server-Cert * * * * * * * * * * * * * * * * * * * * * * u,u,u
>> Core CA certificate * * * * * * * * * * * * * * * * * * * * *CTu,u,u
>> Core CA certificate * * * * * * * * * * * * * * * * * * * * *CT,,
>>
>
> Ok, I think I know what you're seeing. Did you do the same procedure on both
> the master and the replica?
>
> If you did then you created two separate CAs that know nothing about each
> other and don't trust one another.
>
> You probably just want one CA in this case so I'd just pick either the
> master or replica and issue another server certificate from it:
>
> certutil -S -n "Replica-Cert" -s "cn=FQDN" -c "CA certificate" -t "u,u,u" -m
> 1001 -v 120 -d . -k rsa -g 1024 -f /tmp/pwdfile
>
> Then use pk12util to create a PKCS#12 file containing the cert and private
> key:
>
> pk12util -o replica.p12 -d . -n Replica-Cert
>
> Ship this over to the replica and import it with:
>
> pk12util -i replica.p12 -d .
>
> The CA cert should be included in the PKCS#12 file but if it isn't you'll
> need to grab it from the master and install it on the replica.
>
> rob
>
>>
>>
>> On Wed, Sep 8, 2010 at 10:49 PM, Rob Crittenden<rcritten@redhat.com>
>> *wrote:
>>>
>>> John Mancuso wrote:
>>>>
>>>> Two questions:
>>>>
>>>> 1. I have generated self-signed ssl/ca certs trying both the
>>>> "certutil" method from the redhat doc and also the standard "openssl
>>>> x509 req -new" method. After installing the certs and enabling secure
>>>> ldaps replication both result in
>>>>
>>>> slapi_ldap_bind - Error: could not send bind request for id
>>>> [cn=replication manager,cn=config] mech [SIMPLE]: error 81 (Can't
>>>> contact LDAP server) -8172 (Peer's certificate issuer has been marked
>>>> as not trusted by the user.) 11 (Resource temporarily unavailable)
>>>>
>>>> Is there a known issue with self-signed certs?
>>>
>>> No, they work fine. Did you add the CA certificate that signed the server
>>> certificate as well?
>>>
>>> You can verify that the certificate is ok on the server with:
>>>
>>> certutil -V -u V -d /etc/dirsrv/slapd-<YOUR_INSTANCE>
>>>
>>> You are probably just missing the CA certificate. If you have it in PEM
>>> format you can add it via the command-line with:
>>>
>>> certutil -A -d /etc/dirsrv/slapd-<YOUR_INSTANCE> *-n 'Your CA' -t CT,,
>>> -a<
>>> /path/to/ca.pem
>>>
>>> The 'Your CA' here is the nickname of the CA certificate. It is how it
>>> will
>>> appear in the DS console and using certutil -L. Pick something meaningful
>>> to
>>> you.
>>>
>>>> 2. If there is an issue with the above, we may end up purchasing a
>>>> wildcard cert for replicating across subdomains. I know in the HTML
>>>> world some web browsers complain about ssl wildcard certs across
>>>> subdomains. Any possible issues with this approach?
>>>>
>>>> ldaps://supplier_ldap.mycompany.com---->
>>>> *ldaps://consumer_ldap.dev.mycompany.com
>>>
>>> A wildcard cert will work but its probably overkill to buy one just for
>>> this
>>> purpose. self-signed certificates will work fine.
>>>
>>> rob
>>>
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 09-09-2010, 09:11 PM
Rich Megginson
 
Default SSL Cert Issue

John Mancuso wrote:
> That's what it was! thanks. Unfortunately going across subdomains was a no go :
>
> -12276 (Unable to communicate securely with peer: requested domain
> name does not match the server's certificate.
>
> I tried to generate a self signed wildcard (cn=*.mycompany.com) but no
> luck there. Thanks anyways!
>
Use SubjectAltName instead of wildcards -
http://directory.fedoraproject.org/wiki/Howto:SSL#Using_Subject_Alt_Name
> On Thu, Sep 9, 2010 at 9:02 AM, Rob Crittenden <rcritten@redhat.com> wrote:
>
>> John Mancuso wrote:
>>
>>> I followed the exact procedure below numerous times with the same
>>> frustrating error:
>>>
>>>
>>> http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Managing_SSL-Using_certutil.html#certutil-procedure
>>>
>>> !481 $ openssl verify cacert_core.asc
>>> cacert_core.asc: /DC=tv/DC=freewheel/CN=CA cert
>>> error 18 at 0 depth lookup:self signed certificate
>>> OK
>>>
>>> !482 $ openssl verify cacert_PEKdev020.asc
>>> cacert_PEKdev020.asc: /DC=tv/DC=freewheel/CN=CA cert
>>> error 18 at 0 depth lookup:self signed certificate
>>> OK
>>>
>>> !474 $ certutil -V -u V -d . -n "Core CA certificate"
>>> certutil: certificate is valid
>>>
>>> !476 $ certutil -V -u V -d . -n "Core Server-Cert"
>>> certutil: certificate is valid
>>>
>>> I also imported the consumers CA cert into the supplier ... this is
>>> correct? I tried only importing the suppliers CA cert before with the
>>> same issue (trying everything here!)
>>>
>>> This looks strange though (why the duplicate cert):
>>>
>>> !478 $ certutil -d . -L
>>>
>>> Certificate Nickname Trust
>>> Attributes
>>>
>>> SSL,S/MIME,JAR/XPI
>>> Core Server-Cert u,u,u
>>> Core CA certificate CTu,u,u
>>> Core CA certificate CT,,
>>>
>>>
>> Ok, I think I know what you're seeing. Did you do the same procedure on both
>> the master and the replica?
>>
>> If you did then you created two separate CAs that know nothing about each
>> other and don't trust one another.
>>
>> You probably just want one CA in this case so I'd just pick either the
>> master or replica and issue another server certificate from it:
>>
>> certutil -S -n "Replica-Cert" -s "cn=FQDN" -c "CA certificate" -t "u,u,u" -m
>> 1001 -v 120 -d . -k rsa -g 1024 -f /tmp/pwdfile
>>
>> Then use pk12util to create a PKCS#12 file containing the cert and private
>> key:
>>
>> pk12util -o replica.p12 -d . -n Replica-Cert
>>
>> Ship this over to the replica and import it with:
>>
>> pk12util -i replica.p12 -d .
>>
>> The CA cert should be included in the PKCS#12 file but if it isn't you'll
>> need to grab it from the master and install it on the replica.
>>
>> rob
>>
>>
>>> On Wed, Sep 8, 2010 at 10:49 PM, Rob Crittenden<rcritten@redhat.com>
>>> wrote:
>>>
>>>> John Mancuso wrote:
>>>>
>>>>> Two questions:
>>>>>
>>>>> 1. I have generated self-signed ssl/ca certs trying both the
>>>>> "certutil" method from the redhat doc and also the standard "openssl
>>>>> x509 req -new" method. After installing the certs and enabling secure
>>>>> ldaps replication both result in
>>>>>
>>>>> slapi_ldap_bind - Error: could not send bind request for id
>>>>> [cn=replication manager,cn=config] mech [SIMPLE]: error 81 (Can't
>>>>> contact LDAP server) -8172 (Peer's certificate issuer has been marked
>>>>> as not trusted by the user.) 11 (Resource temporarily unavailable)
>>>>>
>>>>> Is there a known issue with self-signed certs?
>>>>>
>>>> No, they work fine. Did you add the CA certificate that signed the server
>>>> certificate as well?
>>>>
>>>> You can verify that the certificate is ok on the server with:
>>>>
>>>> certutil -V -u V -d /etc/dirsrv/slapd-<YOUR_INSTANCE>
>>>>
>>>> You are probably just missing the CA certificate. If you have it in PEM
>>>> format you can add it via the command-line with:
>>>>
>>>> certutil -A -d /etc/dirsrv/slapd-<YOUR_INSTANCE> -n 'Your CA' -t CT,,
>>>> -a<
>>>> /path/to/ca.pem
>>>>
>>>> The 'Your CA' here is the nickname of the CA certificate. It is how it
>>>> will
>>>> appear in the DS console and using certutil -L. Pick something meaningful
>>>> to
>>>> you.
>>>>
>>>>
>>>>> 2. If there is an issue with the above, we may end up purchasing a
>>>>> wildcard cert for replicating across subdomains. I know in the HTML
>>>>> world some web browsers complain about ssl wildcard certs across
>>>>> subdomains. Any possible issues with this approach?
>>>>>
>>>>> ldaps://supplier_ldap.mycompany.com---->
>>>>> ldaps://consumer_ldap.dev.mycompany.com
>>>>>
>>>> A wildcard cert will work but its probably overkill to buy one just for
>>>> this
>>>> purpose. self-signed certificates will work fine.
>>>>
>>>> rob
>>>>
>>>>
>>> --
>>> 389 users mailing list
>>> 389-users@lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 11:49 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org