<div dir="ltr">Hi,<div> </div><div>I've been running F23 + mod_nss 1.0.14-1 for months to get SubjectAltName to work.</div><div>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?</div><div>(I can add karma if needed)</div><div> </div><div>-- john</div></div><div class="gmail_extra"> <div class="gmail_quote">2016-04-25 19:26 GMT+02:00 John Obaterspok <<a href="mailto:john.obaterspok@gmail.com" target="_blank">john.obaterspok@gmail.com</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks Rob!<div> </div><div>I rebuilt the mod_nss-1.0.14-1 version from rawhide for my F23 IPA server and it works like a charm.</div><div> </div><div>Thanks,</div><div> </div><div> john</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"> <div class="gmail_quote">2016-04-25 16:47 GMT+02:00 Rob Crittenden <<a href="mailto:rcritten@redhat.com" target="_blank">rcritten@redhat.com</a>>: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">John Obaterspok wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 2016-02-11 1:34 GMT+01:00 Fraser Tweedale <<a href="mailto:ftweedal@redhat.com" target="_blank">ftweedal@redhat.com</a> <mailto:<a href="mailto:ftweedal@redhat.com" target="_blank">ftweedal@redhat.com</a>>>: On Sun, Feb 07, 2016 at 12:05:19PM +0100, John Obaterspok wrote: > 2016-02-06 23:29 GMT+01:00 Rob Crittenden <<a href="mailto:rcritten@redhat.com" target="_blank">rcritten@redhat.com</a> <mailto:<a href="mailto:rcritten@redhat.com" target="_blank">rcritten@redhat.com</a>>>:<div><div> > > > 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 <a href="https://gitserver.my.lan" rel="noreferrer" target="_blank">https://gitserver.my.lan</a> > >> > >> Previously this worked fine if I had set "git config --global > >> http.sslVerify false" according to > >> <a href="https://www.redhat.com/archives/freeipa-users/2015-November/msg00213.html" rel="noreferrer" target="_blank">https://www.redhat.com/archives/freeipa-users/2015-November/msg00213.html</a> > >> > >> 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@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@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@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@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@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 </div></div> *dns: gitserver.my.lan,ipa.my.lan* principal name: http/ipa.my.lan@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? </blockquote> 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 <a href="https://bugzilla.redhat.com/show_bug.cgi?id=133018" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=133018</a> rob </blockquote></div> </div> </div></div></blockquote></div> </div>