Fedora directory users - Apr 2008 - NSPR "Certificate type not approved for application" error when a TLS-enabled proxy LDAP OpenLDAP server connects to Fedora Directory Server

Hi!

I have a proxy OpenLDAP server (based on slapd-ldap) backend that 
connects to Fedora Directory server.

All is fine if OpenLDAP is configured to connect using non-SSL URI 
without TLS.

However, whenever I try TLS on port 389 or SSL on port 636, OpenLDAP 
uses its server certificate during TLS/SSL negotiation and Fedora 
Directory decides that this certificate usage isn''t good because
it''s
not a client certificate. In FDS logs I can see:

[14/Apr/2008:11:33:33 +0200] conn=1474 fd=65 slot=65 SSL connection from 
IP_OF_OPENLDAP to IP_OF_FDS
[14/Apr/2008:11:33:33 +0200] conn=1474 Netscape Portable Runtime error 
-8101 (Certificate type not approved for application.); unauthenticated 
client E=some_email,CN=hostname,ETC,ETC,; issuer E=ISSUER_DATA
[14/Apr/2008:11:33:33 +0200] conn=1474 op=-1 fd=65 closed - Certificate 
type not approved for application.

Is there a way to relax those requirements in Fedora Directory for this 
particular case (LDAP client that uses a server certificate)?  Like, say 
some tweaks in nss.conf?


-- 
Best Regards,
    Aleksander Adamowski
        GG#: 274614
        ICQ UIN: 19780575 
	http://olo.org.pl

--
Aleksander Adamowski
    Administrator systemów korporacyjnych; Instruktor
    Altkom Akademia S.A. http://www.altkom.pl
    Warszawa, ul. Chłodna 51
    tel. brak
    kom. +48 601-318-080

Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego
Rejestru Sądowego,
KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN.  Adres
rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa.
Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę
przedsiębiorstwa firmy Altkom Akademia S.A.
Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do
własnych celów jest zabronione.
Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne
skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej
wiadomości.
This message contains proprietary information and trade secrets of Altkom
Akademia S.A. company.
Unauthorized use or disclosure of this information to any third party is
prohibited.
If you received this message by mistake, please contact the sender immediately
and delete all copies of this message.

Aleksander Adamowski wrote:
> 
> However, whenever I try TLS on port 389 or SSL on port 636, OpenLDAP 
> uses its server certificate during TLS/SSL negotiation and Fedora 
> Directory decides that this certificate usage isn''t good because
it''s
> not a client certificate. In FDS logs I can see:
> [..]
> [14/Apr/2008:11:33:33 +0200] conn=1474 Netscape Portable Runtime error 
> -8101 (Certificate type not approved for application.); unauthenticated 
> client E=some_email,CN=hostname,ETC,ETC,; issuer E=ISSUER_DATA
> [14/Apr/2008:11:33:33 +0200] conn=1474 op=-1 fd=65 closed - Certificate 
> type not approved for application.
I guess this is because of wrong X.509v3 cert extensions. Maybe you 
should post a text dump of the public-key cert.

openssl x509 -in certfilename.pem -noout -text

Ciao, Michael.

Aleksander Adamowski wrote:
> Hi!
>
> I have a proxy OpenLDAP server (based on slapd-ldap) backend that 
> connects to Fedora Directory server.
>
> All is fine if OpenLDAP is configured to connect using non-SSL URI 
> without TLS.
>
> However, whenever I try TLS on port 389 or SSL on port 636, OpenLDAP 
> uses its server certificate during TLS/SSL negotiation and Fedora 
> Directory decides that this certificate usage isn''t good because
it''s
> not a client certificate. In FDS logs I can see:
>
> [14/Apr/2008:11:33:33 +0200] conn=1474 fd=65 slot=65 SSL connection 
> from IP_OF_OPENLDAP to IP_OF_FDS
> [14/Apr/2008:11:33:33 +0200] conn=1474 Netscape Portable Runtime error 
> -8101 (Certificate type not approved for application.); 
> unauthenticated client E=some_email,CN=hostname,ETC,ETC,; issuer 
> E=ISSUER_DATA
> [14/Apr/2008:11:33:33 +0200] conn=1474 op=-1 fd=65 closed - 
> Certificate type not approved for application.
>
> Is there a way to relax those requirements in Fedora Directory for 
> this particular case (LDAP client that uses a server certificate)?
Do you need to use cert based auth?  If not, just configure the 
application to not use cert. based auth - just use username/password 
auth over SSL (or TLS).  If you must use cert. based auth, you may be 
able to use the certutil command to change the trust flags of the cert - 
see certutil -H.  See also this page for information about cert. based 
auth -
http://directory.fedoraproject.org/wiki/Howto:CertMapping
> Like, say some tweaks in nss.conf?
NSS (Netscape^H^H^H^H^Hwork Security Services) for crypto and nss (name 
switch service - as in nss_ldap) are completely different and 
unfortunately share the same name.

Rich Megginson wrote:
> Do you need to use cert based auth?  If not, just configure the 
> application to not use cert. based auth - just use username/password 
> auth over SSL (or TLS).  If you must use cert. based auth, you may be 
> able to use the certutil command to change the trust flags of the cert 
> - see certutil -H.  See also this page for information about cert. 
> based auth - http://directory.fedoraproject.org/wiki/Howto:CertMapping
Hmm, this has given me an idea for a solution. After switching 
Encryption -> Client Authentication settings of dirsrv from "Allow 
client authentication" to "Do not allow client authentication" I
got
this working.

It seems that whenever certificate authentication is an allowed 
possibility on the FDS server side, OpenLDAP client tries using it even 
if it is operating inside an OpenLDAP server environment (in which case 
it supplies its server certificate as client''s - thus the problem).

This case is special since OpenLDAP server acts as an LDAP client to FDS 
server.
I think the problem is on OpenLDAP side (it shouldn''t use its server 
certificate for client authentication when acting as an LDAP client).
>> Like, say some tweaks in nss.conf?
> NSS (Netscape^H^H^H^H^Hwork Security Services) for crypto and nss 
> (name switch service - as in nss_ldap) are completely different and 
> unfortunately share the same name.
Read carefully: I wasn''t talking about nsswitch.conf (which is for Name
Service Switch), but nss.conf (which is a config file for mod_nss which 
is based on Network Secirity Services library).

The FDS admin server (dirsrv-admin) is based on Apache and it uses 
mod_nss for handling SSL connections.
So inside /etc/dirsrv/admin-serv/nss.conf you can tweak SSL-related 
behaviour of dirsrv-admin.

I thought that there might be a similar method to tweak behaviour of 
dirsrv (although not through nss.conf since dirsrv doesn''t use mod_nss 
and doesn''t contain a http server in any part ), like some undocumented
setting in dse.ldif. However, more correct fix turned out to be disallow 
certificate-based client authentication.

-- 
Best Regards,
    Aleksander Adamowski
        GG#: 274614
        ICQ UIN: 19780575 
	http://olo.org.pl

--
Aleksander Adamowski
    Administrator systemów korporacyjnych; Instruktor
    Altkom Akademia S.A. http://www.altkom.pl
    Warszawa, ul. Chłodna 51
    tel. brak
    kom. +48 601-318-080

Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego
Rejestru Sądowego,
KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN.  Adres
rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa.
Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę
przedsiębiorstwa firmy Altkom Akademia S.A.
Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do
własnych celów jest zabronione.
Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne
skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej
wiadomości.
This message contains proprietary information and trade secrets of Altkom
Akademia S.A. company.
Unauthorized use or disclosure of this information to any third party is
prohibited.
If you received this message by mistake, please contact the sender immediately
and delete all copies of this message.

Aleksander Adamowski wrote:
> Rich Megginson wrote:
>> Do you need to use cert based auth?  If not, just configure the 
>> application to not use cert. based auth - just use username/password 
>> auth over SSL (or TLS).  If you must use cert. based auth, you may be 
>> able to use the certutil command to change the trust flags of the 
>> cert - see certutil -H.  See also this page for information about 
>> cert. based auth - 
>> http://directory.fedoraproject.org/wiki/Howto:CertMapping
> Hmm, this has given me an idea for a solution. After switching 
> Encryption -> Client Authentication settings of dirsrv from "Allow 
> client authentication" to "Do not allow client
authentication" I got
> this working.
>
> It seems that whenever certificate authentication is an allowed 
> possibility on the FDS server side, OpenLDAP client tries using it 
> even if it is operating inside an OpenLDAP server environment (in 
> which case it supplies its server certificate as client''s - thus
the
> problem).
>
> This case is special since OpenLDAP server acts as an LDAP client to 
> FDS server.
> I think the problem is on OpenLDAP side (it shouldn''t use its
server
> certificate for client authentication when acting as an LDAP client).
That should be fine.  Fedora DS can do the same thing e.g. with 
server-to-server chaining and replication, using the server cert for 
client cert auth.  It just depends on the type of cert issued and/or the 
trust flags on the cert.
>
>>> Like, say some tweaks in nss.conf?
>> NSS (Netscape^H^H^H^H^Hwork Security Services) for crypto and nss 
>> (name switch service - as in nss_ldap) are completely different and 
>> unfortunately share the same name.
> Read carefully: I wasn''t talking about nsswitch.conf (which is for
> Name Service Switch), but nss.conf (which is a config file for mod_nss 
> which is based on Network Secirity Services library).
>
> The FDS admin server (dirsrv-admin) is based on Apache and it uses 
> mod_nss for handling SSL connections.
> So inside /etc/dirsrv/admin-serv/nss.conf you can tweak SSL-related 
> behaviour of dirsrv-admin.
Ok.  I thought we were talking about the directory server
only.
>
> I thought that there might be a similar method to tweak behaviour of 
> dirsrv (although not through nss.conf since dirsrv doesn''t use
mod_nss
> and doesn''t contain a http server in any part ), like some 
> undocumented setting in dse.ldif. However, more correct fix turned out 
> to be disallow certificate-based client authentication.
See the RHDS 8.0 Admin Guide, Chapter 12 - 
http://www.redhat.com/docs/manuals/dir-server/ag/8.0/ and 
http://tinyurl.com/688w9y

See also the detailed information for all of the security/encryption 
configuration entries and attributes - http://tinyurl.com/35qddb - there 
is also an apparently undocumented entry cn=RSA, cn=encryption, cn=config.

Rich Megginson wrote:
> That should be fine.  Fedora DS can do the same thing e.g. with 
> server-to-server chaining and replication, using the server cert for 
> client cert auth.  It just depends on the type of cert issued and/or 
> the trust flags on the cert.
If I understand correctly you''re implying that server2server ssl 
connections are handled with the same logic that client2server ssl?

Then it''s strange, since I''m using multi-master replication
with all s2s
connections using SSL (port 636). I''ve generated all the certificates 
(for FDS servers and for OpenLDAP servers) using the same OpenSSL CA 
openssl.cnf config file (but a slightly different configuration section 
WRT subjectAltName field - see below).

The relevant fields of the OpenLDAP server''s certificate are:

        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Cert Type:
                SSL Server
...
            X509v3 Subject Alternative Name:
                email:postmaster@MY_DOMAIN_NAME

While the same fields of the FDS certificate are:

        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Cert Type:
                SSL Server
...
            X509v3 Subject Alternative Name:
                DNS:servername2.MY_DOMAIN_NAME, 
DNS:servername3.MY_DOMAIN_NAME

Other differences are only in key length, crypto algorithms and values 
of serial numbers, fingerprint etc.

So the only one possibly relevant difference is that in OpenLDAP''s cert
the subjectAltName field contains an e-mail address and in Fedora 
Directory Server''s it contains alternative DNS host names of the FDS 
server. Might it be the cause?
>
>>
>> I thought that there might be a similar method to tweak behaviour of 
>> dirsrv (although not through nss.conf since dirsrv doesn''t use
>> mod_nss and doesn''t contain a http server in any part ), like
some
>> undocumented setting in dse.ldif. However, more correct fix turned 
>> out to be disallow certificate-based client authentication.
> See the RHDS 8.0 Admin Guide, Chapter 12 - 
> http://www.redhat.com/docs/manuals/dir-server/ag/8.0/ and 
> http://tinyurl.com/688w9y
>
> See also the detailed information for all of the security/encryption 
> configuration entries and attributes - http://tinyurl.com/35qddb - 
> there is also an apparently undocumented entry cn=RSA, cn=encryption, 
> cn=config.
Yup, I''ve read that but there isn''t anything conclusive over
there. I
was counting on some undocumented configuration attribute that would 
control which usages are allowed in client x.509 certs.

-- 
Best Regards,
    Aleksander Adamowski
        GG#: 274614
        ICQ UIN: 19780575 
	http://olo.org.pl

--
Aleksander Adamowski
    Administrator systemów korporacyjnych; Instruktor
    Altkom Akademia S.A. http://www.altkom.pl
    Warszawa, ul. Chłodna 51
    tel. brak
    kom. +48 601-318-080

Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego
Rejestru Sądowego,
KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN.  Adres
rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa.
Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę
przedsiębiorstwa firmy Altkom Akademia S.A.
Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do
własnych celów jest zabronione.
Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne
skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej
wiadomości.
This message contains proprietary information and trade secrets of Altkom
Akademia S.A. company.
Unauthorized use or disclosure of this information to any third party is
prohibited.
If you received this message by mistake, please contact the sender immediately
and delete all copies of this message.

Aleksander Adamowski wrote:
> Rich Megginson wrote:
>> That should be fine.  Fedora DS can do the same thing e.g. with 
>> server-to-server chaining and replication, using the server cert for 
>> client cert auth.  It just depends on the type of cert issued and/or 
>> the trust flags on the cert.
> If I understand correctly you''re implying that server2server ssl 
> connections are handled with the same logic that client2server ssl?
What I meant was that the server handles any client cert based auth the 
same way, regardless of whether the "client" is a user or another
server.
>
> Then it''s strange, since I''m using multi-master
replication with all
> s2s connections using SSL (port 636). I''ve generated all the 
> certificates (for FDS servers and for OpenLDAP servers) using the same 
> OpenSSL CA openssl.cnf config file (but a slightly different 
> configuration section WRT subjectAltName field - see below).
>
> The relevant fields of the OpenLDAP server''s certificate are:
>
>        X509v3 extensions:
>            X509v3 Basic Constraints:
>                CA:FALSE
>            Netscape Cert Type:
>                SSL Server
> ...
>            X509v3 Subject Alternative Name:
>                email:postmaster@MY_DOMAIN_NAME
>
> While the same fields of the FDS certificate are:
>
>        X509v3 extensions:
>            X509v3 Basic Constraints:
>                CA:FALSE
>            Netscape Cert Type:
>                SSL Server
> ...
>            X509v3 Subject Alternative Name:
>                DNS:servername2.MY_DOMAIN_NAME, 
> DNS:servername3.MY_DOMAIN_NAME
>
> Other differences are only in key length, crypto algorithms and values 
> of serial numbers, fingerprint etc.
>
> So the only one possibly relevant difference is that in OpenLDAP''s
> cert the subjectAltName field contains an e-mail address and in Fedora 
> Directory Server''s it contains alternative DNS host names of the
FDS
> server. Might it be the cause?
I''m not sure how NSS handles certificate verification with 
subjectAltName.  I know that in order for the validation to work without 
subjectAltName, the leftmost RDN in the subjectDN must be cn=FQDN of the 
server e.g. cn=ldap1.example.com, ou=Fedora Directory Server, 
dc=example, dc=com

I''m also not sure if that applies to cert based
auth.
>>
>>>
>>> I thought that there might be a similar method to tweak behaviour
of
>>> dirsrv (although not through nss.conf since dirsrv doesn''t
use
>>> mod_nss and doesn''t contain a http server in any part ),
like some
>>> undocumented setting in dse.ldif. However, more correct fix turned 
>>> out to be disallow certificate-based client authentication.
>> See the RHDS 8.0 Admin Guide, Chapter 12 - 
>> http://www.redhat.com/docs/manuals/dir-server/ag/8.0/ and 
>> http://tinyurl.com/688w9y
>>
>> See also the detailed information for all of the security/encryption 
>> configuration entries and attributes - http://tinyurl.com/35qddb - 
>> there is also an apparently undocumented entry cn=RSA, cn=encryption, 
>> cn=config.
> Yup, I''ve read that but there isn''t anything conclusive
over there. I
> was counting on some undocumented configuration attribute that would 
> control which usages are allowed in client x.509 certs.
>
Ok.  I''m not sure what NSS is complaining about here.  If NSS is 
complaining about the hostname in the subjectDN or the subjectAltName 
doesn''t match the actual server, I don''t think that makes
sense in the
context of cert based auth, since a client will usually not have an 
associated FQDN.  So I believe it''s complaining that the cert was not 
issued as an SSL client cert.  I do know that you can issue a cert that 
can be used for both SSL server and SSL client use.  I''m not sure if
you
can use certutil -M to modify the trust flags of a server cert after 
issuance to allow it to be used for SSL client use.  The guys at 
news.mozilla.org:mozilla.dev.tech.crypto would know for sure.

Finally, there doesn''t appear to be a way in Fedora DS to allow other 
types of certificates to be used for client cert auth, or to ignore 
problems of this nature.

Aleksander Adamowski wrote:
> 
> The relevant fields of the OpenLDAP server''s certificate are:
What about the keyUsage and extendedKeyUsage extensions?

Ciao, Michael.

Rich Megginson wrote:
> I''m not sure how NSS handles certificate verification with 
> subjectAltName.  I know that in order for the validation to work without 
> subjectAltName, the leftmost RDN in the subjectDN must be cn=FQDN of the 
> server e.g. cn=ldap1.example.com, ou=Fedora Directory Server, 
> dc=example, dc=com
Yes, for server certs which are validated by the client.
> I''m also not sure if that applies to cert based auth.
It doesn''t.

Ciao, Michael.

Aleksander Adamowski wrote:
> It seems that whenever certificate authentication is an allowed 
> possibility on the FDS server side, OpenLDAP client tries using it even 
> if it is operating inside an OpenLDAP server environment (in which case 
> it supplies its server certificate as client''s - thus the
problem).
OpenLDAP client lib supplies the client cert which was configured for 
back-ldap. Check OpenLDAP''s ldap.conf or slapd.conf and the relevant 
man-pages.
> I think the problem is on OpenLDAP side (it shouldn''t use its
server
> certificate for client authentication when acting as an LDAP client).
I think the problem is with your particular configuration and the certs 
you''re using.

Ciao, Michael.

Michael Ströder wrote:
> Aleksander Adamowski wrote:
>>
>> The relevant fields of the OpenLDAP server''s certificate are:
>
> What about the keyUsage and extendedKeyUsage extensions?
>
> Ciao, Michael.
These aren''t present, unfortunately.

I didn''t place keyUsage in the openssl.cnf section used for server 
certificates...

-- 
Best Regards,
    Aleksander Adamowski
        GG#: 274614
        ICQ UIN: 19780575 
	http://olo.org.pl

--
Aleksander Adamowski
    Administrator systemów korporacyjnych; Instruktor
    Altkom Akademia S.A. http://www.altkom.pl
    Warszawa, ul. Chłodna 51
    tel. brak
    kom. +48 601-318-080

Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego
Rejestru Sądowego,
KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN.  Adres
rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa.
Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę
przedsiębiorstwa firmy Altkom Akademia S.A.
Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do
własnych celów jest zabronione.
Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne
skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej
wiadomości.
This message contains proprietary information and trade secrets of Altkom
Akademia S.A. company.
Unauthorized use or disclosure of this information to any third party is
prohibited.
If you received this message by mistake, please contact the sender immediately
and delete all copies of this message.

Michael Ströder wrote:
> Aleksander Adamowski wrote:
>> It seems that whenever certificate authentication is an allowed 
>> possibility on the FDS server side, OpenLDAP client tries using it 
>> even if it is operating inside an OpenLDAP server environment (in 
>> which case it supplies its server certificate as client''s -
thus the
>> problem).
>
> OpenLDAP client lib supplies the client cert which was configured for 
> back-ldap. Check OpenLDAP''s ldap.conf or slapd.conf and the
relevant
> man-pages. \
The point is that there''s _no_ client cert, I don''t intend to
have
mutual authentication here - I''d like slapd-ldap _not_ authenticate 
itself with a certificate.
I''d like it to behave like an ordinary certificate-less client. But it 
chooses to use its server certificate to authenticate itself as a client 
to FDS server.

I don''t see any options to force _no client authentication_ - neither
in
slapd-ldap(5), nor slapd.conf(5), nor ldap.conf(5).

I''m using OpenLDAP 2.3.39.

-- 
Best Regards,
    Aleksander Adamowski
        GG#: 274614
        ICQ UIN: 19780575 
	http://olo.org.pl

--
Aleksander Adamowski
    Administrator systemów korporacyjnych; Instruktor
    Altkom Akademia S.A. http://www.altkom.pl
    Warszawa, ul. Chłodna 51
    tel. brak
    kom. +48 601-318-080

Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego
Rejestru Sądowego,
KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN.  Adres
rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa.
Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę
przedsiębiorstwa firmy Altkom Akademia S.A.
Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do
własnych celów jest zabronione.
Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne
skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej
wiadomości.
This message contains proprietary information and trade secrets of Altkom
Akademia S.A. company.
Unauthorized use or disclosure of this information to any third party is
prohibited.
If you received this message by mistake, please contact the sender immediately
and delete all copies of this message.

Aleksander Adamowski wrote:
> Michael Ströder wrote:
>> Aleksander Adamowski wrote:
>>>
>>> The relevant fields of the OpenLDAP server''s certificate
are:
>>
>> What about the keyUsage and extendedKeyUsage extensions?
>>
> These aren''t present, unfortunately.
IIRC they have to be defined.

Example lines for openssl.cnf:
keyUsage                = digitalSignature,keyEncipherment
extendedKeyUsage        = serverAuth

Ciao, Michael.