Koozali.org: home of the SME Server

certificate problem

Offline tomeratch

  • *
  • 24
  • +0/-0
certificate problem
« on: April 23, 2017, 01:00:36 PM »
Hello my sme 9.1 server seems to have a small problem of renew certificates each time i make changes to the server and giving me this message after each update or when the daily cronjob is called :conf-mosd_ssl
iget this message :
Quote
Running event handler: /etc/e-smith/events/actions/generic_template_expand
Apr 23 08:53:21 linux-mail esmith::event[30691]: expanding /home/e-smith/ssl.pem/pem
Apr 23 08:53:22 linux-mail esmith::event[30691]: You are about to be asked to enter information that will be incorporated
Apr 23 08:53:22 linux-mail esmith::event[30691]: into your certificate request.
Apr 23 08:53:22 linux-mail esmith::event[30691]: What you are about to enter is what is called a Distinguished Name or a DN.
Apr 23 08:53:22 linux-mail esmith::event[30691]: There are quite a few fields but you can leave some blank
Apr 23 08:53:22 linux-mail esmith::event[30691]: For some fields there will be a default value,
Apr 23 08:53:22 linux-mail esmith::event[30691]: If you enter '.', the field will be left blank.
also get a mail with the same output every day.
Also seems like each time i make some changes to the server the certificate is renewed as well .
Any suggestions what can cause this ?
Thanks in advance

Offline DanB35

  • ****
  • 764
  • +0/-0
    • http://www.familybrown.org
Re: certificate problem
« Reply #1 on: April 23, 2017, 01:34:56 PM »
I've seen something like this before, but I don't remember the cause or what I did to fix it.  However, today, a good option is to dispense with the self-signed certificate entirely, in favor of a free, trusted cert from Let's Encrypt.  See https://wiki.contribs.org/Letsencrypt
......

Offline tomeratch

  • *
  • 24
  • +0/-0
Re: certificate problem
« Reply #2 on: April 23, 2017, 01:43:27 PM »
Thank you but i'm just fine with the self signed cert ...
I have another backup machine that does not do this and I want to know what caused the problem in the first place ... might be a misconfig or something .
the backup machine does not renew the certificates as the production server does.
any help solving this is appreciated .
might deleting the .pem file solve this? will it be recreated after reconfigure? all tho i see the .pem file's date modified is also updated when the new certificate is created... meaning each time i make changes or daily conf-mosd_ssl is called
« Last Edit: April 23, 2017, 01:52:11 PM by tomeratch »

Offline mmccarn

  • *
  • 2,627
  • +10/-0
Re: certificate problem
« Reply #3 on: April 23, 2017, 03:12:09 PM »
I'm completely guessing, but...

perhaps an international character, special character, single or double quote, or a space in one of the fields involved in certificate creation would cause a problem.

Check the 'Directory' tab in server-manager, the db settings used in creating self-signed certs for anything odd.

This command will list the db entries I found mentioned in the template fragments in /etc/e-smith/templates/home/e-smith:
Code: [Select]
echo -e "\n\n" \
"SystemName: \n\t$(config get SystemName)\n\n" \
"DomainName:\n\t$(config get DomainName)\n\n" \
"modSSL CommonName:\n\t$(config getprop modSSL CommonName)\n" \
"ldap defaultCity:\n\t$(config getprop ldap defaultCity)\n\n" \
"ldap defaultCompany:\n\t$(config getprop ldap defaultCompany)\n\n" \
"ldap defaultDepartment:\n\t$(config getprop ldap defaultDepartment)\n\n"

When building the certificate, modSSL commonName will be used if present, but will default to "SystemName"."DomainName" if it does not exist.  I don't know what happens if it exists but is blank.

A further 'email' field is built using "admin@" plus DomainName

Several fields are cropped before use:
 defaultCity at 128 chars
 defaultCompany at 64 chars
 defaultDepartment at 64 chars
 email at 64 chars
 commonName at 64 chars

One of these fields that is long enough to get cropped, that also contains quotes, parentheses, braces, or brackets may end up containing only the initial piece of the pair (which might cause problems).

Offline tomeratch

  • *
  • 24
  • +0/-0
Re: certificate problem
« Reply #4 on: April 23, 2017, 03:35:09 PM »
thank you for your response here is the output (to me it looks ok)  :
Quote
SystemName:
        linux-mail

 DomainName:
        jpost.com

 modSSL CommonName:

 ldap defaultCity:
        Jerusalem

 ldap defaultCompany:
        JPOST

 ldap defaultDepartment:

Offline tomeratch

  • *
  • 24
  • +0/-0
Re: certificate problem
« Reply #5 on: April 23, 2017, 04:28:52 PM »
Hi there Solved the issue by entering server-manager/Directory  and filling the blank fields...
Thank you all for the fast reply's and help .

guest22

Re: certificate problem
« Reply #6 on: April 24, 2017, 06:57:39 AM »
Interesting...

Offline tomeratch

  • *
  • 24
  • +0/-0
Re: certificate problem
« Reply #7 on: April 24, 2017, 07:51:45 AM »
yep it seems blank fields in domain name and default location was the problem .. now the certificate is no longer renewed.. maybe it has to do with the upgrade I did from 7.6 to 9.1 I checked the old 7.6 backup I had and all fields were blank there and had no issue there but on 9.1 it seems it matters .

Offline Mophilly

  • *
  • 384
  • +0/-0
    • Mophilly
Re: certificate problem
« Reply #8 on: April 28, 2017, 08:40:11 PM »
Not meaning to hijack this thread, but my question is related.

I encountered a warning about an expired self-signed certificate. However, the machine in question has a commercial wildcard cert installed; installed about a year ago. The problem was reported today.

Using the script provided by tomeratch, I see the CommonName field is empty. defaultCity, defaultCompany, and defaultDepartment have values.

If I enter a value, say, "*.mydomain.com" in modSSL CommonName and reboot the system, is it reasonable to expect that resolve to the issue?
« Last Edit: April 28, 2017, 08:42:31 PM by Mophilly »
- Mark

Offline mmccarn

  • *
  • 2,627
  • +10/-0
Re: certificate problem
« Reply #9 on: April 29, 2017, 12:57:47 PM »
If I enter a value, say, "*.mydomain.com" in modSSL CommonName and reboot the system, is it reasonable to expect that resolve to the issue?
I doubt it.

If your server is supposed to be using a commercial cert I don't see why updating the info used to generate the self-signed cert would help.

You need to figure out why and where the commercial cert installation has left the self-signed cert in use.

Offline Mophilly

  • *
  • 384
  • +0/-0
    • Mophilly
Re: certificate problem
« Reply #10 on: April 29, 2017, 05:33:21 PM »
Thank you for the comment.

I ran a test against the server using https://www.ssllabs.com/ssltest/
The results indicated the cert is installed correctly. I asked the end user to check again and was told the warning came from a Symantec product that is used to scan the user's system.

For the moment I consider this issue settled, unless the end user reports the problem again.
- Mark

Offline DanB35

  • ****
  • 764
  • +0/-0
    • http://www.familybrown.org
Re: certificate problem
« Reply #11 on: April 29, 2017, 09:19:25 PM »
I asked the end user to check again and was told the warning came from a Symantec product that is used to scan the user's system.
Ah, yes, entirely plausible.  A number of "internet security" products operate as a MITM to try to prevent threats in HTTPS websites.
......

Offline Mophilly

  • *
  • 384
  • +0/-0
    • Mophilly
Re: certificate problem
« Reply #12 on: April 29, 2017, 10:28:36 PM »
One last follow up. The end user ran the scan software again and this time it gave a clean report. So, I believe the cert files were properly made and installed, but that I overlooked one config db setting.

Now, to give a more clear picture, the server in question is not the primary server but one covered by a wildcard certificate for the domain.

Thanks for the advice and feed back. :-)
- Mark

Offline mmccarn

  • *
  • 2,627
  • +10/-0
Re: certificate problem
« Reply #13 on: April 30, 2017, 03:17:39 PM »
Users may also see random certificate errors when using public hotspots or hotel wifi that use a captive portal to authorize internet access.

All traffic is sent to the captive portal until after the user authenticates or agrees to the terms of service.  This can result in email clients, VPNs, open web pages, etc attempting access a secure site before the network connection is established, which will generate certificate errors.