Changes

From SME Server
Jump to navigationJump to search

Certificates Concepts (view source)

Revision as of 03:51, 13 January 2023

671 bytes added ,  03:51, 13 January 2023
no edit summary
Line 1: Line 1: −
{{usefulnote}}
+
Starting SME 10 default SSL self signed certificate integrates all your domains associated to your server, but also LAN IP, WAN IP (if any and if static). Also it is now regenerated, whenever the domain list or IP is updated, or on every year.
 +
 
 +
SME 10 also offers SNI support for your apache web server. SNI is a technology allowing recent browser to wait for a specific answer allowing the server to know what domain they want to access before starting the encrypted transaction, this allow httpd to choose the appropirate certificate if multiple are available.
 +
 
 +
SME Server is designed in a way that the same certificate is shared between all the exposed services offering SSL/TLS communication to a user : httpd, pop, imap, ftp, radiusd, ldap, smtp. The practical approach is if all your hosted domain are included in the SSL ceertificate for httpd... then you can also connect to the imap and smtp using the same domains without any alert from the client software.{{usefulnote}}
 
===Self signed certificates===
 
===Self signed certificates===
−
The certificate created by sme by default is a self signed certificate. That means it is issued by sme server and as such has not been tested or authenticated by any external certificate issuing Authority eg VeriSign & others etc.
+
The certificate created by sme by default is a self signed certificate. That means it is issued by SME Server and as such has not been tested or authenticated by any external certificate issuing Authority eg VeriSign & others etc.
    
This also means that the root certificate which is installed in most browsers by default (so the browser knows about all the commercial certificates and happily accepts them), does not know about the sme server self signed certificate, and therefore a web browser does not trust the certificate that is presented to it when a user tries to access a https site on your web server.
 
This also means that the root certificate which is installed in most browsers by default (so the browser knows about all the commercial certificates and happily accepts them), does not know about the sme server self signed certificate, and therefore a web browser does not trust the certificate that is presented to it when a user tries to access a https site on your web server.
Line 7: Line 11:  
Therefore the users must install the self signed certificate into their browser the very first time they access your web server using https. After that they will not be asked again when they next access your site using https, as long as they are accessing from the same PC/browser.
 
Therefore the users must install the self signed certificate into their browser the very first time they access your web server using https. After that they will not be asked again when they next access your site using https, as long as they are accessing from the same PC/browser.
 
The problem is that with current generation web browsers, they issue very scary warnings that can put off many people and make them scared to access your site at all, and certainly reluctant to install a certificate about which they are being given a security breach type of warning.
 
The problem is that with current generation web browsers, they issue very scary warnings that can put off many people and make them scared to access your site at all, and certainly reluctant to install a certificate about which they are being given a security breach type of warning.
−
  −
There is another issue here, you should advise users to browse to https://servername.yourmaindomain.com/webmail (for example) and that name will match the name on the self signed certificate issued by sme server. That at least prevents name discrepancies, but still does not avoid the need to install the certificate on the very first https access.
  −
  −
Obviously external DNS records have to support that URL ie you would usually setup a wildcard in external DNS records that makes *.yourmaindomain.com resolve to your server IP.
      
====How to change your certificate====
 
====How to change your certificate====
   −
Since SME version 7.1.3, the functionality to configure a Common Name in the certificate is included in the main SME packages and can be configured as follows:
+
The functionality to configure a Common Name in the certificate is included in the main SME packages and can be configured as follows:
    
  config setprop modSSL CommonName www.domain.com
 
  config setprop modSSL CommonName www.domain.com
Line 26: Line 26:  
see this forum thread [http://forums.contribs.org/index.php?topic=33109.15] and bug report [http://bugs.contribs.org/show_bug.cgi?id=1689]
 
see this forum thread [http://forums.contribs.org/index.php?topic=33109.15] and bug report [http://bugs.contribs.org/show_bug.cgi?id=1689]
   −
====Expiration time of the self signed certificate====
+
==== Customization of Self Signed Certificate ====
−
One last point to note is that the sme self signed certificate is valid for one year, and it gets automatically renewed by sme server functionality on the anniversary of the installation date of the sme server OS.
+
Global values of the cert
−
 
+
{| class="wikitable"
−
So if a user installs your self signed certificate into their browser (ie the one issued by sme), then in a year or less time, they will again receive warning messages when they access your site using https, as your original security certificate has expired. The answer is for them to install the newly created certificate into their web browser again, but by that time they have forgotten what they did a year ago, and go into panic mode again and get scared of the warnings, and end up not accessing your site at all due to fear. The result, another time wasting call to your tech support line.
+
|+config setprop key property yourvalue
−
 
+
!information
−
There is a mechanism (custom-templates) to specify how long your sme certificate will last for, eg you can change the validity to say 5 years (instead of 1 yr), if you feel that security model is acceptable, and that will save users from having to reinstall the sme certificate into their browsers every year eg they will be asked again to install it in 5 years (or less) depending when they first installed it.
+
!key
−
 
+
!property
−
See /etc/e-smith/templates/home/e-smith/ssl.crt
+
!default
−
 
+
|-
−
Copy that fragment from the templates tree to the templates-custom tree
+
|time in day before renewal
−
 
+
|modSSL
−
Do
+
|KeyLifeInDays
−
mkdir -p /etc/e-smith/templates-custom/home/e-smith/
+
|365
−
cp /etc/e-smith/templates/home/e-smith/ssl.crt /etc/e-smith/templates-custom/home/e-smith/ssl.crt
+
|-
−
 
+
|Key Size
−
then do
+
|modSSL
−
nano -w /etc/e-smith/templates-custom/home/e-smith/ssl.crt
+
|KeySize
−
 
+
|4096
−
and change the value for KEYLIFEINDAYS
+
|-
−
on the first line to say 1826 for 5 years.
+
|country
−
 
+
|modSSL
−
To to save & exit press the following keys at the same time
+
|Country
−
ctrl x
+
| --
−
 
+
|-
−
Then you need to force sme server to immediately create a new self signed certificate (with the longer validity period) by issuing the following commands. Note to replace the filenames with the correct file/key names applicable to your server.
+
|state /province
−
rm /home/e-smith/ssl.crt/servername.domain.com.crt
+
|modSSL
−
rm /home/e-smith/ssl.key/servername.domain.com.key
+
|State
−
rm /home/e-smith/ssl.pem/servername.domain.com.pem
+
| ----
−
signal-event post-upgrade
+
|-
−
signal-event reboot
+
|common name
 +
|modSSL
 +
|CommonName
 +
|$SystemName.$DomainName
 +
|-
 +
|City
 +
|ldap
 +
|defaultCity
 +
|Ottawa
 +
|-
 +
|Company
 +
|ldap
 +
|defaultCompany
 +
|XYZ Corporation
 +
|-
 +
|Company Department
 +
|ldap
 +
|defaultDepartment
 +
|Main
 +
|}
 +
The list of entries is populated fromt he script /sbin/e-smith/generate-subjectaltnames.Here are the options you have access
 +
{| class="wikitable"
 +
|+config setprop key property yourvalue
 +
!information
 +
!key
 +
!property
 +
!default
 +
|-
 +
|Add Domains
 +
|modSSL
 +
|AddDomains
 +
|enabled
 +
|-
 +
|Add Hosts
 +
|modSSL
 +
|AddHosts
 +
|enabled
 +
|-
 +
|state /province
 +
|modSSL
 +
|State
 +
| ----
 +
|-
 +
|common name
 +
|modSSL
 +
|CommonName
 +
|$SystemName.$DomainName
 +
|-
 +
|City
 +
|ldap
 +
|defaultCity
 +
|Ottawa
 +
|-
 +
|Company
 +
|ldap
 +
|defaultCompany
 +
|XYZ Corporation
 +
|-
 +
|Company Department
 +
|ldap
 +
|defaultDepartment
 +
|Main
 +
|}
   −
or to more thoroughly remove all old & unwanted files do the following (make a backup of files in these folders first, if you have commercial certificates). You should answer y to accept each file removal one at a time.
     −
rm /home/e-smith/ssl.crt/*
+
modify the values you want, then issue
−
rm /home/e-smith/ssl.key/*
  −
rm /home/e-smith/ssl.pem/*
  −
signal-event post-upgrade
  −
signal-event reboot
     −
Then add the new 5 year certificate to your browser, and no more questions from your browser until five years time when the certificate validity expires.
+
signal-event ssl-update
    
===Commercial certificates===
 
===Commercial certificates===
Line 97: Line 154:     
When initially creating and ordering the certificate and supplying the domain name(s) to your chosen commercial supplier, you must include all domains that your server is hosting. sme server only supports one ssl certificate, so therefore to avoid errors for https access using any hosted domain name, the certificate must be created correctly. sme does not cater for multiple certificates for  different domains, as it is not technically possible.
 
When initially creating and ordering the certificate and supplying the domain name(s) to your chosen commercial supplier, you must include all domains that your server is hosting. sme server only supports one ssl certificate, so therefore to avoid errors for https access using any hosted domain name, the certificate must be created correctly. sme does not cater for multiple certificates for  different domains, as it is not technically possible.
 +
 +
=== Commercial certificate for a single VirtualHost using Apache SNI ===
 +
This is new in SME 10. You can keep the generik certificate for all your VirtualHost of apache httpd, except some where you want to define a specific one, which could be a commercial one.
 +
 +
the use case could be site in ibay "mystore" host a shopping website, and you want to nuy a certificate which comes with insurances for commercial transactions. You can then buy your certificate for shop.myownbusiness.tld including only this domain and keep using Let's Encrypt  certificate for blog.myownbusiness.tld wiki..myownbusiness.tld and www.myownbusiness.tld.
 +
 +
do the following<syntaxhighlight lang="bash">
 +
mkdir /home/e-smith/shop.myownbusiness.tld
 +
</syntaxhighlight>Upload there : your acquired certificate, associated private key, and if any chain certificate.
 +
 +
then issue<syntaxhighlight lang="bash">
 +
db domains shop.myownbusiness.tld setprop DomainSSLCertificateFile  /home/e-smith/shop.myownbusiness.tld/cert.pem
 +
db domains shop.myownbusiness.tld setprop DomainSSLCertificateKeyFile  /home/e-smith/shop.myownbusiness.tld/key.pem
 +
# and if you have a chain certificate provided :
 +
db domains shop.myownbusiness.tld setprop DomainSSLCertificateChainFile  /home/e-smith/shop.myownbusiness.tld/chain.pem
 +
 +
signal-event remote-access update
 +
</syntaxhighlight>
    
====Migrating commercial certificates from Windows to Linux====
 
====Migrating commercial certificates from Windows to Linux====
Line 109: Line 184:  
The end result is you have the two files, .key and .crt. Do not implement the last three steps re importing the certificate to Apache, instead follow the instructions here: http://wiki.contribs.org/Certificates_Concepts#Commercial_certificates
 
The end result is you have the two files, .key and .crt. Do not implement the last three steps re importing the certificate to Apache, instead follow the instructions here: http://wiki.contribs.org/Certificates_Concepts#Commercial_certificates
   −
=====Testing the migration before final deployment=====
+
=====Testing the migration befoObviously external DNS records have to support that URL ie you would usually setup a wildcard in external DNS records that makes *.yourmaindomain.com resolve to your server IP.re final deployment=====
 
Once the SME server is restarted, you can test the certificate from a Windows workstation (without disrupting the customers site) by doing:
 
Once the SME server is restarted, you can test the certificate from a Windows workstation (without disrupting the customers site) by doing:
   Line 125: Line 200:     
===Freely available certificates===
 
===Freely available certificates===
−
If you choose to create your own certificate using one of the Howtos eg the [[Custom_CA_Certificate|CACert Howto]], then the first time visitors access your site (https), they will still get asked to install the certificate into their browser. This is because CACert does not pay Microsoft $10,000 or more regularly to have their root certificate automatically installed in Internet Explorer (& updates which also update the root certifcate) etc. The same goes for other major brands of web browsers, although work is progressing to improve the relationship between CACert & other free certificate issuers and various web browser authors.
+
In the last years the best approach is to use the service of Let's Encrypt free certificate. They offer multiple way of verifying you are the owner of the domain, but this is not the purpose of this page. SME Server can use those certificate using the contrib [[Letsencrypt]]. Simply follow this page content and you will have a certificate working for all your SME Server Services.
 +
 
 +
In the past the only option used to be CACert. If you choose to create your own certificate using one of the Howtos eg the [[Custom_CA_Certificate|CACert Howto]], then the first time visitors access your site (https), they will still get asked to install the certificate into their browser. This is because CACert does not pay Microsoft $10,000 or more regularly to have their root certificate automatically installed in Internet Explorer (& updates which also update the root certifcate) etc. The same goes for other major brands of web browsers, although work is progressing to improve the relationship between CACert & other free certificate issuers and various web browser authors.
    
You can refer your visitors to the CACert website and get them to install the CACert root certificate and they will no longer be questioned about the certificate on your server, as your CACert certificate is now trusted by their browser (as it has the CACert root certificate installed). You can go either way really, get users to install your CACert certificate or get them to install the CACert root certificate.
 
You can refer your visitors to the CACert website and get them to install the CACert root certificate and they will no longer be questioned about the certificate on your server, as your CACert certificate is now trusted by their browser (as it has the CACert root certificate installed). You can go either way really, get users to install your CACert certificate or get them to install the CACert root certificate.
   −
You will still have renewal issues with CACert certificates for example, as they are only valid for 6 months, unless you join the special recognition program and show proof of identity to a authorised human being in your area, when they are then valid for 2 years. Ultimately at some time in the future, you will need to renew the CACert certificate, and install that new certificate onto sme server. Then when a user's web browser accesses https for the first time, it will object to the authenticity of the new certificate, thus needing to be reinstalled again, or install the CACert root certificate again. You can't win actually as users will always be chasing their own tail reinstalling certificates, albeit infrequently !
+
You will still have renewal issues with CACert certificates for example, as they are only valid for 6 months, unless you join the special recognition program and show proof of identity to a authorized human being in your area, when they are then valid for 2 years. Ultimately at some time in the future, you will need to renew the CACert certificate, and install that new certificate onto sme server. Then when a user's web browser accesses https for the first time, it will object to the authenticity of the new certificate, thus needing to be reinstalled again, or install the CACert root certificate again. You can't win actually as users will always be chasing their own tail reinstalling certificates, albeit infrequently !
−
 
  −
===Problem with email client===
  −
Also if using the self signed certificate, instead of configuring your email client to use say mail.yourdomain.com for sending and receiving mail server names, then change that to servername.yourdomain.com, and that way the email client will not create a warning/error each time you access the mail system on your server ie by clicking the Send/Receive button in the email client ie the certificate name will match the requested server name.
      
===Multiple domains===
 
===Multiple domains===
 
If you have multiple hosted domains, then you may need to use a certificate that covers all those domains, if you want users to access individual domain name URLs, the CACert How to details that.
 
If you have multiple hosted domains, then you may need to use a certificate that covers all those domains, if you want users to access individual domain name URLs, the CACert How to details that.
−
Otherwise if using the self signed certificate just get users to access https://servername.maindomain.com/webmail irregardless of whether they are using a different domain for their receiving/sending email address. In webmail, change the default senders address for each user to match the domain they are supposed to be using.
+
 
−
Note that sme server only has one version of webmail installed and it serves all users of all domains.
+
If trying to access to any domain pointing to the server and not included in the certificate you will end up with a warning from your browser.
    
===Custom Certificate===
 
===Custom Certificate===
Line 166: Line 240:     
This article is based on information given by mary in [http://forums.contribs.org/index.php/topic,42522.0.html this thread] in the contribs.org Forums.
 
This article is based on information given by mary in [http://forums.contribs.org/index.php/topic,42522.0.html this thread] in the contribs.org Forums.
 +
 +
=== Related Pages ===
 +
 +
* deprecated page on [[Certificate]]
 +
* how to integrate certificate from Go Daddy [[Certificate_Integration_GoDaddy_Certificate]]
 +
* how to integrate certificate from Thawte [[Certificate_Integration_Thawte_Certificate]]
 +
* contrib to upload certificate in place of main modssl cert  [[Certificate_ssl_management]]
 +
* contrib for using Let's encrypt certificate for the domains you want : [[Letsencrypt]]
 +
* contrib to manage your CA and certificate using the server manager [[PHPki]]
 +
* own CA signed certificates for all your servers [[Certificates_signed_by_own_CA]]
 +
* Cacert custom certificates [[Custom_CA_Certificate]]
 +
 
----
 
----
 
[[Category:Howto]]
 
[[Category:Howto]]
 
[[Category:Administration:Certificates]]
 
[[Category:Administration:Certificates]]
 
[[Category:Security]]
 
[[Category:Security]]
Unnilennium
Super Admin, Wiki & Docs Team, Bureaucrats, Interface administrators, Administrators
3,254

edits

Retrieved from "https://wiki.koozali.org/Special:MobileDiff/41931"

Navigation menu