LDAP Certificate and Hostname mismatch

UCS - Univention Corporate Server
, , ,
#1

Hi,

I had a plain samba4 domain and the host name was mdc01. Then I got in contact with ucs and fell in love :heart_eyes: . Thanks for that :slight_smile:

I used the domain takeover to the new server ucs01. 99% worked great (thanks again for that :+1: )

But I notice, that new user cannot login. sssd rejects the connection via ldaps, since it contacts mdc01 and gets an certificate with cn=ucs01:

dennis@linux:~ $ env LDAPTLS_CACERT=./ldapserver.pem ldapsearch -d1 -x -H ldaps://mdc01.domain.tld/ -D "Administrator@domain.tld" -W sAMAccountName=du
ldap_url_parse_ext(ldaps://mdc01.domain.tld/)
ldap_create
ldap_url_parse_ext(ldaps://mdc01.domain.tld:636/??base)
Enter LDAP Password: 
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP mdc01.domain.tld:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.5.101:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect: 
connect success
TLS: hostname (mdc01.domain.tld) does not match common name in certificate (ucs01.domain.tld).
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

As far as I see my options are now:

  • re-issue the certificate to mdc01
  • re-issue the certificate with a SAN certificate
  • rename the server and reinstall samba like this: Changing HOSTNAME on UCS , but I’m not sure, if the ldap data will survive

Are there any other options, a preferred way or what are your opinions regarding this?

Best regards!

#2

Hey,

re-issuing the server certificate with the full host name seems to be the easiest option in my view. Does the server actually have an FQDN at the moment? Meaning
 what’s the output of hostname -f? Additionally, what’s the output of ucr get domainname and ucr get ldap/base? Depending on that information I might actually change my mind and recommend reinstallation.

Kind regards,
mosu

#3

I used the same domain name, but not the same server name:

root@ucs01:~# ucr get domainname
domain.tld
root@ucs01:~# ucr get ldap/base
dc=domain,dc=tld
root@ucs01:~# hostname -f
ucs01.domain.tld

The clients expect the name mdc01. The name and the IP were taken over during the AD takeover:

root@ucs01:~# dig mdc01.domain.tld

; <<>> DiG 9.9.5-9+deb8u13A~4.2.1.201708081700-Univention <<>> mdc01.domain.tld
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33109
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mdc01.domain.tld.		IN	A

;; ANSWER SECTION:
mdc01.domain.tld.	900	IN	CNAME	ucs01.domain.tld.
ucs01.domain.tld.	900	IN	A	192.168.5.101

;; AUTHORITY SECTION:
domain.tld.		900	IN	NS	ucs01.domain.tld.

;; Query time: 3 msec
;; SERVER: 192.168.5.101#53(192.168.5.101)
;; WHEN: Sat Feb 03 22:50:20 CET 2018
;; MSG SIZE  rcvd: 96

Edit: Are there any recommended univention tools to re-issue the certificate or “just” using the openssl command to change the certificates in /etc/univention/ssl/?

#4

Could find at least, how to re-issue the certificates: Erneuern der SSL-Zertifikate

My idea was to adjust the openssl.cnf containing the host name to add two more subjects as SANs, but:

root@ucs01:/etc/univention/ssl# grep DNS ucs01.domain.tld/openssl.cnf 
subjectAltName = DNS:ucs01.domain.tld, DNS:ucs01, DNS:mdc01.domain.tld, DNS:mdc01
root@ucs01:/etc/univention/ssl# for i in *.$domainname; do univention-certificate renew -name $i -days 730; done
Renew certificate: ucs01.domain.tld
Using configuration from /etc/univention/ssl/openssl.cnf
Revoking Certificate 05.
Data Base Updated
Using configuration from /etc/univention/ssl/openssl.cnf
Using configuration from /etc/univention/ssl/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName           :PRINTABLE:'DE'
stateOrProvinceName   :PRINTABLE:'DE'
localityName          :PRINTABLE:'DE'
organizationName      :PRINTABLE:'domain.tld'
organizationalUnitName:PRINTABLE:'Univention Corporate Server'
commonName            :PRINTABLE:'ucs01.domain.tld'
emailAddress          :IA5STRING:'ssl@domain.tld'
Certificate is to be certified until Feb  4 00:03:39 2020 GMT (730 days)
    
root@ucs01:/etc/univention/ssl# openssl x509 -text -noout -in ucs01.domain.tld/cert.pem | grep DNS
                DNS:ucs01.domain.tld, DNS:ucs01

univention-certificate renew do not respect this file and the other (more global one) ssl conf file do not contain the SAN part :persevere: Does someone now, where this programm gets the SANs from?

#5

Hey,

Ugh, that’s an ugly situation. All UCS services and servers expect to use and see the host name as it is now. Meaning that if you re-issue the certificate for the host ucs01 with host name mdc01, you’ll end up with not a lot working afterwards anymore because now all UCS services will fail to connect.

Yeah, that’s exactly what you should do. That way both the old and the new name are part of the certificate. It should satisfy both UCS services and your other clients. The common name field isn’t all that important nowadays.

I seem to remember that the renew process re-uses the existing CSR (certificate signing request), and that one only includes the subjectAltName properties from the configuration as they were when the CSR was generated. Therefore you’ll have to re-generate the CSR (the req.pem file) from your config now. Maybe something like this:

cd /etc/univention/ssl/ucs01
openssl req -batch -config openssl.cnf -new -key private.key -out req.pem
chown "root:DC Backup Hosts" req.pem
chmod 0640 req.pem

Afterwards try the renew process again. If it works, don’t forget to restart all services, or better yet, reboot.

Oh, and create a full backup of /etc/univention/ssl before you do any of those things above :grinning:

Kind regards,
mosu

#6

Ah, ok, makes sense. But it seems that some env variables are missing:

root@ucs01:/etc/univention/ssl/ucs01# openssl req -batch -config openssl.cnf -new -key private.key -out req.pem
error on line 31 of openssl.cnf
139778132506256:error:0E065068:configuration file routines:STR_COPY:variable has no value:conf_def.c:584:line 31

It seems to be an OpenSSL issue, solved here: UCS Openssl request signing error

DEFAULT_CRL_DAYS="$(/usr/sbin/univention-config-registry get ssl/crl/validity)"
: ${DEFAULT_CRL_DAYS:=10}
DEFAULT_DAYS="$(/usr/sbin/univention-config-registry get ssl/default/days)"
: ${DEFAULT_DAYS:=1825}
DEFAULT_MD="$(/usr/sbin/univention-config-registry get ssl/default/hashfunction)"
: ${DEFAULT_MD:=sha256}
DEFAULT_BITS="$(/usr/sbin/univention-config-registry get ssl/default/bits)"
: ${DEFAULT_BITS:=2048}

export DEFAULT_MD DEFAULT_BITS DEFAULT_CRL_DAYS
openssl req -batch -config openssl.cnf -new -key private.key -out req.pem

Now it works! Thanks a lot.

#7

Oh right, I totally forgot to mention them. Sorry about that :slight_smile:

Mastodon