[Freeipa-users] nss unrecognized name alert with SAN name
John Obaterspok
john.obaterspok at gmail.com
Sun Jun 26 18:37:34 UTC 2016
Hi,
I've been running F23 + mod_nss 1.0.14-1 for months to get SubjectAltName
to work.
F24 update brings back mod_nss to 1.0.12-4 and now SubjectAltName doesn't
work any more. Is there any chance 1.0.14 will make it in as an F24 update?
(I can add karma if needed)
-- john
2016-04-25 19:26 GMT+02:00 John Obaterspok <john.obaterspok at gmail.com>:
> Thanks Rob!
>
> I rebuilt the mod_nss-1.0.14-1 version from rawhide for my F23 IPA server
> and it works like a charm.
>
> Thanks,
>
> john
>
> 2016-04-25 16:47 GMT+02:00 Rob Crittenden <rcritten at redhat.com>:
>
>> John Obaterspok wrote:
>>
>>>
>>> 2016-02-11 1:34 GMT+01:00 Fraser Tweedale <ftweedal at redhat.com
>>> <mailto:ftweedal at redhat.com>>:
>>>
>>> On Sun, Feb 07, 2016 at 12:05:19PM +0100, John Obaterspok wrote:
>>> > 2016-02-06 23:29 GMT+01:00 Rob Crittenden <rcritten at redhat.com
>>> <mailto:rcritten at redhat.com>>:
>>>
>>> >
>>> > > John Obaterspok wrote:
>>> > >
>>> > >> Hi,
>>> > >>
>>> > >> I have a ipa.my.lan and a cname gitserver.my.lan pointing to
>>> ipa.my.lan
>>> > >>
>>> > >> I recently started to get nss error "SSL peer has no
>>> certificate for the
>>> > >> requested DNS name." when I'm accesing my
>>> https://gitserver.my.lan
>>> > >>
>>> > >> Previously this worked fine if I had set "git config --global
>>> > >> http.sslVerify false" according to
>>> > >>
>>>
>>> https://www.redhat.com/archives/freeipa-users/2015-November/msg00213.html
>>> > >>
>>> > >> Now I tried to solve this by adding a SubjectAltName to the
>>> > >> HTTP/ipa.my.lan certitficate like this:
>>> > >>
>>> > >> status: MONITORING
>>> > >> stuck: no
>>> > >> key pair storage:
>>> > >>
>>>
>>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
>>> > >> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>>> > >> certificate:
>>> > >>
>>>
>>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
>>> > >> Certificate DB'
>>> > >> CA: IPA
>>> > >> issuer: CN=Certificate Authority,O=MY.LAN
>>> > >> subject: CN=ipa.my.lan,O=MY.LAN
>>> > >> expires: 2018-02-06 19:24:52 UTC
>>> > >> dns: gitserver.my.lan,ipa.my.lan
>>> > >> principal name: http/ipa.my.lan at MY.LAN
>>> > >> key usage:
>>> > >>
>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>> > >> eku: id-kp-serverAuth,id-kp-clientAuth
>>> > >> pre-save command:
>>> > >> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
>>> > >> track: yes
>>> > >> auto-renew: yes
>>> > >>
>>> > >> But I still get the below error:
>>> > >>
>>> > >> * NSS error -12182 (SSL_ERROR_UNRECOGNIZED_NAME_ALERT)
>>> > >> * SSL peer has no certificate for the requested DNS name
>>> > >>
>>> > >
>>> > > What version of mod_nss? It recently added support for SNI. You
>>> can try
>>> > > turning it off by adding NSSSNI off to
>>> /etc/httpd/conf.d/nss.conf but I'd
>>> > > imagine you were already relying on it.
>>> > >
>>> > >
>>> > Hi,
>>> >
>>> > Turning it off didn't help
>>> >
>>> > I'm on F23 with latest updates so I have mod_nss-1.0.12-1
>>> > I noticed it worked if I set "ServerName gitserver.my.lan" in
>>> > gitserver.conf, but then I got the NAME ALERT when accessing
>>> ipa.my.lan.
>>> >
>>> > I then tried to put ipa.conf in <VirtualHost *:443> but then I
>>> got error
>>> > about SSL_ERROR_RX_RECORD_TOO_LONG
>>> >
>>> > gitserver.conf has this:
>>> >
>>> > <VirtualHost *:443>
>>> > DocumentRoot /opt/wwwgit
>>> > SetEnv GIT_PROJECT_ROOT /opt/wwwgit
>>> > SetEnv GIT_HTTP_EXPORT_ALL
>>> > SetEnv REMOTE_USER $REDIRECT_REMOTE_USER
>>> > ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
>>> >
>>> > ServerName gitserver.my.lan
>>> >
>>> > <Directory "/usr/libexec/git-core">
>>> > Options Indexes
>>> > AllowOverride None
>>> > Require all granted
>>> > </Directory>
>>> >
>>> > <Directory "/opt/wwwgit">
>>> > Options Indexes
>>> > AllowOverride None
>>> > Require all granted
>>> > </Directory>
>>> >
>>> > <LocationMatch "/git/">
>>> > #SSLRequireSSL
>>> > AuthType Kerberos
>>> > AuthName "Kerberos Login"
>>> > KrbAuthRealm MY.LAN
>>> > Krb5KeyTab /etc/httpd/conf/ipa.keytab
>>> > KrbMethodNegotiate on
>>> > KrbMethodK5Passwd off # Set to on to query for pwd if
>>> negotiation
>>> > failed due to no ticket available
>>> > KrbSaveCredentials on
>>> > KrbVerifyKDC on
>>> > KrbServiceName HTTP/ipa.my.lan at MY.LAN
>>> >
>>> > AuthLDAPUrl
>>> ldaps://ipa.my.lan/dc=my,dc=lan?krbPrincipalName
>>> > AuthLDAPBindDN
>>> "uid=httpbind,cn=sysaccounts,cn=etc,dc=my,dc=lan"
>>> > AuthLDAPBindPassword "secret123abc"
>>> > Require ldap-group
>>> cn=ipausers,cn=groups,cn=accounts,dc=my,dc=lan
>>> > </LocationMatch>
>>> >
>>> > </VirtualHost>
>>> >
>>> >
>>> > Any more ideas what I do wrong?
>>>
>>> It was suggested that this may be due to the certificate not being
>>> compliant with RFC 2818. This is likely true, but I think it is not
>>> likely to be the problem. You can use `openssl s_client` to confirm
>>> what certificate the server is sending:
>>>
>>> openssl s_client -showcerts \
>>> -servername gitserver.my.lan -connect gitserver.my.lan:443
>>>
>>> This will dump the certificates (in PEM format), which you can copy
>>> to a file examine with `opeenssl x509 -text < cert.pem`.
>>>
>>> Feel free to reply with the output; I am happy to have a closer
>>> look.
>>>
>>> Hi Fraser,
>>>
>>> *cough*, I didn't see this until now :)
>>>
>>> Anyway,
>>>
>>> [admin at ipa ~]$ openssl s_client -showcerts -servername gitserver.my.lan
>>> -connect gitserver.my.lan:443
>>> CONNECTED(00000003)
>>> 140404557162360:error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
>>> unrecognized name:s23_clnt.c:769:
>>> ---
>>> no peer certificate available
>>> ---
>>> No client certificate CA names sent
>>> ---
>>> SSL handshake has read 7 bytes and written 227 bytes
>>> ---
>>> New, (NONE), Cipher is (NONE)
>>> Secure Renegotiation IS NOT supported
>>> Compression: NONE
>>> Expansion: NONE
>>> No ALPN negotiated
>>> SSL-Session:
>>> Protocol : TLSv1.2
>>> Cipher : 0000
>>> Session-ID:
>>> Session-ID-ctx:
>>> Master-Key:
>>> Key-Arg : None
>>> Krb5 Principal: None
>>> PSK identity: None
>>> PSK identity hint: None
>>> Start Time: 1461568003
>>> Timeout : 300 (sec)
>>> Verify return code: 0 (ok)
>>> ---
>>>
>>>
>>> [root at ipa ~]# ipa-getcert list
>>> Number of certificates and requests being tracked: 8.
>>> Request ID '20160206184156':
>>> status: MONITORING
>>> stuck: no
>>> key pair storage:
>>>
>>> type=NSSDB,location='/etc/dirsrv/slapd-MY-LAN',nickname='Server-Cert',token='NSS
>>> Certificate DB',pinfile='/etc/dirsrv/slapd-MY-LAN/pwdfile.txt'
>>> certificate:
>>>
>>> type=NSSDB,location='/etc/dirsrv/slapd-MY-LAN',nickname='Server-Cert',token='NSS
>>> Certificate DB'
>>> CA: IPA
>>> issuer: CN=Certificate Authority,O=my.lan
>>> subject: CN=ipa.my.lan,O=my.lan
>>> expires: 2017-12-23 22:50:30 UTC
>>> principal name: ldap/ipa.my.lan at my.lan
>>> key usage:
>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>> eku: id-kp-serverAuth,id-kp-clientAuth
>>> pre-save command:
>>> post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv
>>> MY-LAN
>>> track: yes
>>> auto-renew: yes
>>> Request ID '20160206192447':
>>> status: MONITORING
>>> stuck: no
>>> key pair storage:
>>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
>>> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>>> certificate:
>>> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
>>> Certificate DB'
>>> CA: IPA
>>> issuer: CN=Certificate Authority,O=my.lan
>>> subject: CN=ipa.my.lan,O=my.lan
>>> expires: 2018-02-06 19:24:52 UTC
>>> *dns: gitserver.my.lan,ipa.my.lan*
>>> principal name: http/ipa.my.lan at my.lan
>>> key usage:
>>> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>>> eku: id-kp-serverAuth,id-kp-clientAuth
>>> pre-save command:
>>> post-save command: /usr/lib64/ipa/certmonger/restart_httpd
>>> track: yes
>>> auto-renew: yes
>>>
>>>
>>> Any ideas?
>>>
>>
>> It's a bug in mod_nss 1.0.12. It shouldn't return a hard failure, it
>> should use the default VH instead (this was fixed in 1.0.13). I filed
>> https://bugzilla.redhat.com/show_bug.cgi?id=133018
>>
>> rob
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160626/cf8ff8f6/attachment.htm>
More information about the Freeipa-users
mailing list