Difference between revisions of "Certificates Concepts"
Unnilennium (talk | contribs) |
Unnilennium (talk | contribs) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
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 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 | + | 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 certificate 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. | ||
| Line 17: | Line 17: | ||
config setprop modSSL CommonName www.domain.com | config setprop modSSL CommonName www.domain.com | ||
| − | + | signal-event ssl-update | |
| − | |||
| − | signal-event | ||
| − | |||
{{Note box | The public certificate (crt) is derived from the private key, so the key has to be generated first before you can generate the certificate otherwise generating of the certificate will fail with cryptic messages}} | {{Note box | The public certificate (crt) is derived from the private key, so the key has to be generated first before you can generate the certificate otherwise generating of the certificate will fail with cryptic messages}} | ||
| Line 125: | Line 122: | ||
===Commercial certificates=== | ===Commercial certificates=== | ||
| + | |||
| + | ==== Commercial certificate used in place of self signed for whole server ==== | ||
| + | Fast and easy solution is to use the contrib to upload your certificate obtained from a third party : [[Certificate ssl management]] . The following informations are more to help you understanding the process behind. | ||
| + | |||
If you use a commercially available certificate & pay money for it, the organisation who issues the certificate pays big money to Microsoft & Mozilla etc to have their root certificate installed in the browser by default. That's why if you use a good quality commercial certificate on your server, then when a visitor to your site accesses https://.... , they will not be asked anything about the certificate mismatching or not being installed etc, as the browser already knows that certificates from say VeriSign are legitimate and happily accepts the connection without question, as it is already trusted. Same for other major brands of commercial certificates. | If you use a commercially available certificate & pay money for it, the organisation who issues the certificate pays big money to Microsoft & Mozilla etc to have their root certificate installed in the browser by default. That's why if you use a good quality commercial certificate on your server, then when a visitor to your site accesses https://.... , they will not be asked anything about the certificate mismatching or not being installed etc, as the browser already knows that certificates from say VeriSign are legitimate and happily accepts the connection without question, as it is already trusted. Same for other major brands of commercial certificates. | ||
| Line 135: | Line 136: | ||
/home/e-smith/ssl.crt/ | /home/e-smith/ssl.crt/ | ||
/home/e-smith/ssl.key/ | /home/e-smith/ssl.key/ | ||
| − | + | ||
| − | In the process of copying it is OK to overwrite the existing files if they are the | + | Also if your CA provided you witth a chain certificate you should create a place to put the chained certificate: |
| − | It | + | mkdir /home/e-smith/ssl.chainfile |
| + | chmod 700 /home/e-smith/ssl.chainfile | ||
| + | In the process of copying it is NOT OK to overwrite the existing files if they are the self signed generated certificate, as SME will generated them on a regular basis as a failsafe in case something goes wrong with your other certificates. | ||
| + | It is a good idea to delete any existing files in those folders, to keep your system clean, except for the one in use and the self generated ones. | ||
| + | |||
| + | {{Warning box|SME Server 10 and above will maintain a self signed certificate on all time using the hostname and primary domain to generate the name of the files. If you happen to use the same filename for your commercial certificates they will be overwritten on next running event or cron task.}} | ||
Then issue the following db commands so that sme server knows about these these "commercial certificate" files, rather than using the default "self signed" certificate files. | Then issue the following db commands so that sme server knows about these these "commercial certificate" files, rather than using the default "self signed" certificate files. | ||
| − | config setprop modSSL crt /home/e-smith/ssl.crt/{domain}.crt | + | config setprop modSSL crt /home/e-smith/ssl.crt/imported_{domain}.crt |
| − | config setprop modSSL key /home/e-smith/ssl.key/{domain}.key | + | config setprop modSSL key /home/e-smith/ssl.key/imported_{domain}.key |
| + | if needed configure the chain certificate: | ||
| + | config setprop modSSL CertificateChainFile /home/e-smith/ssl.chainfile/imported_{domain}.crt | ||
Note to replace {domain}.crt and {domain}.key with the actual names of your files eg | Note to replace {domain}.crt and {domain}.key with the actual names of your files eg | ||
yourdomain.com.crt and yourdomain.com.key | yourdomain.com.crt and yourdomain.com.key | ||
| − | Follow the above commands | + | Follow the above commands : |
| − | signal-event | + | signal-event ssl-update |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
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 === | + | ==== 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. | 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. | ||
| Line 170: | Line 173: | ||
db domains shop.myownbusiness.tld setprop DomainSSLCertificateChainFile /home/e-smith/shop.myownbusiness.tld/chain.pem | db domains shop.myownbusiness.tld setprop DomainSSLCertificateChainFile /home/e-smith/shop.myownbusiness.tld/chain.pem | ||
| − | signal-event | + | signal-event ssl-update |
</syntaxhighlight> | </syntaxhighlight> | ||
| Line 184: | Line 187: | ||
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 | + | =====Testing the migration before 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 212: | Line 215: | ||
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. | 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. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=== Related Pages === | === Related Pages === | ||
Latest revision as of 13:42, 17 January 2023
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 certificate for httpd... then you can also connect to the imap and smtp using the same domains without any alert from the client software.
Is this article helpful to you?
Please consider donating or volunteering
Thank you!
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.
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.
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.
How to change your certificate
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 signal-event ssl-update
see this forum thread [1] and bug report [2]
Customization of Self Signed Certificate
Global values of the cert
| information | key | property | default |
|---|---|---|---|
| time in day before renewal | modSSL | KeyLifeInDays | 365 |
| Key Size | modSSL | KeySize | 4096 |
| country | modSSL | Country | -- |
| state /province | modSSL | State | ---- |
| 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
| 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 |
modify the values you want, then issue
signal-event ssl-update
Commercial certificates
Commercial certificate used in place of self signed for whole server
Fast and easy solution is to use the contrib to upload your certificate obtained from a third party : Certificate ssl management . The following informations are more to help you understanding the process behind.
If you use a commercially available certificate & pay money for it, the organisation who issues the certificate pays big money to Microsoft & Mozilla etc to have their root certificate installed in the browser by default. That's why if you use a good quality commercial certificate on your server, then when a visitor to your site accesses https://.... , they will not be asked anything about the certificate mismatching or not being installed etc, as the browser already knows that certificates from say VeriSign are legitimate and happily accepts the connection without question, as it is already trusted. Same for other major brands of commercial certificates.
Tips for incorporating a commercial certificate into sme server can be found in this forum post
http://forums.contribs.org/index.php/topic,37634.0.html
The process requires that the crt & key files provided by your commercial certificate issuer, be copied to your sme server (by whichever means is most suitable for you eg place them in an ibay and copy using ssh/Putty). Typically the appropriate file type would be copied to each of:
/home/e-smith/ssl.crt/ /home/e-smith/ssl.key/
Also if your CA provided you witth a chain certificate you should create a place to put the chained certificate:
mkdir /home/e-smith/ssl.chainfile chmod 700 /home/e-smith/ssl.chainfile
In the process of copying it is NOT OK to overwrite the existing files if they are the self signed generated certificate, as SME will generated them on a regular basis as a failsafe in case something goes wrong with your other certificates. It is a good idea to delete any existing files in those folders, to keep your system clean, except for the one in use and the self generated ones.
Then issue the following db commands so that sme server knows about these these "commercial certificate" files, rather than using the default "self signed" certificate files.
config setprop modSSL crt /home/e-smith/ssl.crt/imported_{domain}.crt
config setprop modSSL key /home/e-smith/ssl.key/imported_{domain}.key
if needed configure the chain certificate:
config setprop modSSL CertificateChainFile /home/e-smith/ssl.chainfile/imported_{domain}.crt
Note to replace {domain}.crt and {domain}.key with the actual names of your files eg yourdomain.com.crt and yourdomain.com.key
Follow the above commands :
signal-event ssl-update
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
mkdir /home/e-smith/shop.myownbusiness.tld
Upload there : your acquired certificate, associated private key, and if any chain certificate. then issue
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 ssl-update
Migrating commercial certificates from Windows to Linux
Based on this forum post http://forums.contribs.org/index.php/topic,46752.0.html
This example refers to migrating a free StartCom SSL certificate from a Windows SBS 2008 Server to a SME server.
StartCom give out free SSL certificates compatible with IE and Firefox which are only good for HTTPS.
To migrate the SSL certificate (rather than buying & installing a new one) follow these instructions: http://rackerhacker.com/2007/03/23/exporting-ssl-certificates-from-windows-to-linux/
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
Once the SME server is restarted, you can test the certificate from a Windows workstation (without disrupting the customers site) by doing:
1. Add the FQDN and internal IP Address of the SME server to the file
c:\windows\system32\drivers\etc\hosts
in the same format as the sample in the file.
2. Ping the FQDN of the SME server (the public FQDN, not the local one) to test it resolves correctly to the new SME server's internal IP address.
Then open a web browser to the SME server using HTTPS.
The address bar of the browser should correctly display the acceptance of the certificate instead of the usual "Do you want to accept this untrusted site..." message.
Freely available certificates
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 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 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 !
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 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.
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
