I have an SMT server whose hostname is “smt”. Using yast ca_mgm, I create a certificate for it, whose common name is “smt”.
On the SMT client, I run clientSetup4SMT.sh. After accepting the certificate and agreeing to start the registration, I get this error message:
/usr/bin/SUSEConnect --write-config --url https://smt/center/regsvc
SUSEConnect error: OpenSSL::SSL::SSLError: hostname "smt" does not match the server certificate
I found that the message is generated in Ruby SSL code, but I don’t know enough of Ruby to understand what exactly is checked.
Funnily, neither curl nor wget complain about the certificate when they access https://smt.
Where does the mismatch between hostname and certificate come from? Where can I find more information?
Is the Yast error related to the certificate error? If not, how can I address it?
[QUOTE=bausch;56644]I have an SMT server whose hostname is “smt”. Using yast ca_mgm, I create a certificate for it, whose common name is “smt”.
On the SMT client, I run clientSetup4SMT.sh. After accepting the certificate and agreeing to start the registration, I get this error message:
/usr/bin/SUSEConnect --write-config --url https://smt/center/regsvc
SUSEConnect error: OpenSSL::SSL::SSLError: hostname "smt" does not match the server certificate
I found that the message is generated in Ruby SSL code, but I don’t know enough of Ruby to understand what exactly is checked.
Funnily, neither curl nor wget complain about the certificate when they access https://smt.
Where does the mismatch between hostname and certificate come from? Where can I find more information?
Is the Yast error related to the certificate error? If not, how can I address it?[/QUOTE]
All over in the docs it states to use FQDN, so I would suggest reinstalling SMT using smt.yourdomain.abc and see if that helps.
I reinstalled SMT and was delighted to see that the repos I had mirrored earlier are still mirrored.
On the other hand, I get the same error when setting up the client. I created a new certificate with FQDN as common name, and the message complains that the FQDN doesn’t match the server certificate.
As part of Public Key Infrastructure (PKI) which is the infrastructure of
public keys, certificate authorities (CA), and relies on other protocols
like Domain Name Service (DNS), one of the most basic checks is that the
address the client was given (by you) matches the Subject line of the
certificate that the server presents.
In your original post you were going to https://smt/ meaning you are
telling your system to somehow resolve ‘smt’ to an IP address, and then
the TLS layer is going to confirm that the certificate coming from that IP
address has a Subject, or Subject Alternative Name (SAN), of ‘smt’ ‘smt’
is not a valid DNS address, as it has no domain component, so now
presumably you have fixed the SMT side by having smt.your-organization.tld
or something, but your client is still being told to go to ‘smt’.
While using simple hostnames is sometimes appealing because of its
brevity, at the end of the day it i snot valid in DNS, so you should
always use a proper DNS name, e.g. smt.your-organization.tld, when putting
addresses in places, so the systems can do proper verification of
certificates. Otherwise, while you may have encrypted connections, they
are no more secure than an attacker’s bogus certificate; the data may be
secure from onlookers, but you’re still having a conversation directly
with an attacker, and the client, unless it errors as it is in your case,
has no way of trusting a valid server while rejecting a malicious one,
meaning no security.
See if changing your SUSEConnect parameter helps. If you do not have an
actual DNS entry for the full address, you’ll need to fix that in DNS first.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
Well, my hope was that by re-creating the certificate in Yast I would have a valid certificate. This was not the case (except that curl and wget seemed to be happy). I just gave up trying to understand all this and started from scratch, i.e. installing the OS. The certificate is working now, but my SMT saga continues:
# smt-staging createrepo SLES12-SP3-Updates sle-12-x86_64 --testing
(...)
Repository successfully generated at /repo/testing/SUSE/Updates/SLE-SERVER/12-SP3/x86_64/update/.
# smt-staging createrepo SLES12-SP3-Updates sle-12-x86_64 --production
Testing repository does not exist or is not generated properly, cannot generate production repository.
Generate the testing repository first.
I will create a new question if I don’t find a solution here.