Topic: SSL certificates

[ElFroggio]

Hi,

SME 9.1. I currently have a RapidSSL certificate on the primary domain (which I want to keep).

Is it possible to have other certificates for the virtual hosts? and if so, can I use letsencrypt?

Thanks

Syv

[Daniel B.]

No, this is not supported for now. You can only have a single certificate. But this single certificate can cover several different host/domain names (so if you go with Letsencrypt, it can cover your primary domain and all your other ones)

[ElFroggio]

1. Thanks for letting me know, it wasn't clear (at least to me) from the docs.
2. The problem with letsencrypt is that the certficate are only valid for 3 month and then have to be renewed. There's a script for automatically renewing it but it's too much of a pain for the email clients/end-users. Once a year would be 'almost ok'

I will have to look into: PositiveSSL Multi-Domain at $35/yr with 3 domains included

Thanks for the info

Syv

[Daniel B.]

2. The problem with letsencrypt is that the certficate are only valid for 3 month and then have to be renewed. There's a script for automatically renewing it but it's too much of a pain for the email clients/end-users. Once a year would be 'almost ok'

It doesn't matter how often it's renewed. It could even be every days without nobody noticing. Unlike traditionnal commercial certificate, renewal is done automatically, so you don't even have to bother once a year. And the change will be transparent to clients (as long as they use a hostname included in the certificate to reach it, eg if they use mail.domain.tld, then you just need to be sure mail.domain.tls is one of the valid name of the certificate)

[DanB35]

There's a script for automatically renewing it but it's too much of a pain for the email clients/end-users.

Why do you think the frequency of renewal has any effect on the email end-users?

[janet]

ElFroggio

...... And the change will be transparent to clients (as long as they use a hostname included in the certificate to reach it, eg if they use mail.domain.tld, then you just need to be sure mail.domain.tls is one of the valid name of the certificate)

....and that is why it is good practice (IMO) to set the CommonName in your server SSL config as www.domain.tld
That way web access or email access both use www.domain.tld, which is the same as the certificate (when you configure everything that way).
See
https://wiki.contribs.org/Email_-_Setting_up_E-mail_clients_for_SME_8.0#Configure_Common_Name_for_self_signed_Certificate

[DanB35]

Use a Let's Encrypt cert, and you can trivially put www.yourdomain.tld and mail.yourdomain.tld on the same cert, as well as up to 98 other hostnames.

Granted, the convention of assigning hostnames based on function goes way back to when the WWW server, the FTP server, and the mail server were most likely different boxes.  If it's all on the same box, that convention doesn't make much sense; it'd be much more sensible to either simply use yourdomain.tld as the hostname, or assign something meaningful (billing.yourdomain.tld, sales.yourdomain.tld, whatever).  But sticking with the convention of function-based hostnames, and then using the "wrong" (i.e., different than the function you're using) hostname just to match the cert, just doesn't make sense.  Not when, for about 10 minutes' work and no money, you can get a trusted cert that covers all the functions/hostnames you want to use, and renews automatically indefinitely.

[ElFroggio]

The problem with LetEncrypt is not on the server side, the problem is on the client side. The certificates are for 3 months, then renewed. This means that the users have to renew/get the new certificate every 2 month.

The end users have no idea nor understand why. There are 2 kind of users:

• Press and accept everything
• Stop and will not touch the computer until somebody comes to fix it

The minimum that I need is a yearly certificate.

Thanks

Syv

[DanB35]

This means that the users have to renew/get the new certificate every 2 month.

No, they don't.  The users don't need to do anything with the certificate.  The server serves the cert when they connect, the client observes that it's issued by a trusted CA, and it goes merrily along.  Absolutely no user interaction is required (if any interaction is required, it's probably a bug, and I'd appreciate hearing specific details).  I speak from experience here; I eat my own dog food.  I have a Let's Encrypt cert on my server, it runs the automatic renewal every 60 days, and it's completely transparent to me and my users.  No web browser alerts to the new cert, no mail client that I've seen (including iOS and Android apps, and desktop apps under MacOSX, Windows, and Linux) complains, and the Owncloud client apps accept it silently as well.  This is the way it's supposed to work.

Why do you believe that users have to do anything when the server obtains a new cert?  Google's certs are only good for 90 days, but your users don't have to do anything when Google renews a cert.  Every other TLS-enabled website changes its cert periodically (they all have expiration dates, and they can't be good for more than about 3 years), and it's completely transparent to the end-users.  Why should your users be impacted with you renew a cert?  The only possible reason would be if you're accustomed to using certs issued by non-trusted CAs.

Edit:  Perhaps it would be better to ask: what are your users seeing now when you renew/change a cert?

[ElFroggio]

Outlook does complain and ask the user if s/he wants to store the new certificate. Then that's it until the next one. This happens with both self-signed and the rapidssl (which I currently use) certificates.

Is there a way of getting Outlook to not complain about the new certificate that has to be imported?

Thanks

Syv

[DanB35]

Outlook 2007 under Windows 7 connects to my mail server without issues, but it's the only version I have handy to check.  I'll PM you with login credentials on my server to test with whatever client software you want.

[janet]

ElFroggio

Outlook does complain and ask the user if s/he wants to store the new certificate.

Are you using older version of Windows operating system & older versions of web browser eg Internet Explorer.
Please advise what versions (release number) of OS & browsers you are using & Outlook too.

Older systems do not import the root certificate store automatically if they are too old & if they are not regularly updated.
Part of the update is the root certificate store information (from external certificate providers), which your browser needs to know about in order to check against a certificate being presented at login.