Hi guys, Some time late last night I decided it would be a great thing for my website mail to be certified by a trusted third party. Being a true skimp I purchased a certificate from GoDaddy that would cover www.example.com My issue is this: No matter what I do and which ever help forum I try the result is the same, it just doesn't work. http://www.howtoforge.com/forums/showthread.php?t=27606 Keeps using my original certificate when I followed this tutorial http://www.howtoforge.com/perfect-server-debian-squeeze-with-bind-and-dovecot-ispconfig-3-p2 Can someone please make this easy for me?? I have my servers hostname as mail.example.com, but I want people to access their webmail via www.example.com/webmail (as per tutorial). I also have the webmail listening and redirecting on port 50443 so when people go www.example.com/webmail a redirect takes them to https://www.example.com:50443/webmail Is my understanding of certificates wrong in that if you have a certificate for www.example.com it certifies anything www.example.com/anything-you-want??? Please explain it to me thanks in advance Steve
And why should we do that? My guess is that nobody has responded because you're asking for "everything under the sun" in a single post. Unless your Web-server (presumably Apache) is configured to listen for SSL requests on port 50433, this will not work. While it is certainly possible to run make Webmail available on any port desired, you should have a good reason for wanting to do so, as it is a non-standard configuration. You have this correct. The port number is the problem. What happens when you remove port 50443 from the equation altogether?
Thanks for the reply - cbj4074 Good point, teach me then please Well I apologize for the "difficulty" of this question(s) but seeing that it all relates to my issue which I thought is quite simple in itself - Configuring a GoDaddy certificate for a ISPConfig setup. Seems funny if I don't post enough information on forums those who help complain about not enough information, if I post too much they complain as well. Well I followed this tutorial - http://www.howtoforge.com/extending-perfect-server-debian-squeeze-ispconfig-3 - to extend the debian security installation and it told me to configure for webmail to be received on port 50443. Ok first bit of helpful information... I will remove the part of the tutorial that requires the port changes from standard to unknown. But I don't see why I can't have ISPConfig running on port 50443 along with Roundcube. If you could explain that to me that would be great.
I apologize for being a bit brash, but please understand that none of us are paid for the time we spend here. As such, nobody owes anybody anything. Those who understand ISPConfig inside and out have spent countless hours troubleshooting (and have endured considerable hair-loss in many cases) in order to come to that level of understanding. Fortunately, they're willing to share at least some of that knowledge. We're dealing with some very complex issues here (most of which have nothing to do with ISPConfig, directly), and your question is less simple than you may think. SSL, by its complex nature, carries with it many moving parts. I'll never complain about too much information unless it's clear that no effort has been made to troubleshoot on one's own. (You've shown at least some effort, hence my reply.) Now, all of that said... Thank you for posting the second tutorial that you followed. That's the most helpful thing you've posted yet (and I say that without sarcasm); it helps us determine the origin of your actions. While I understand the logic behind running Apache virtual hosts on non-standard ports, doing so qualifies as "security by obscurity" as far as I'm concerned. Any sophisticated piece of software is going to find ISPConfig whether it's running on port 80 or some random port much higher in the available range. Given that you've already followed the tutorial, there's no reason to undo those changes. It wasn't clear from your initial post that Webmail does function as expected (aside from the certificate issue). When you make statements such as it is difficult for us to know what, exactly doesn't work. We need screenshots, precise error messages, etc. To be clear, the only issue is that the wrong certificate (presumably ISPConfig's default certificate) is being used instead of the one you purchased from GoDaddy whenever you attempt to access Webmail? I haven't read the entire tutorial that you followed, but I don't see anything in there about installing your own SSL certificate. While that in itself is fine, it would be helpful if you told us what steps you took to install the GoDaddy certificate. We'll assume that you already have the actual certificate (.csr, .key, and .crt files), or, alternatively, a .pem file, as well as the CA's (GoDaddy's) .bundle file. If this is not the case, please do say so.
thank you cbj4074 I also would like to mention that I really do appreciate the help I receive from this forum, I know that you guys all do this for free and using up your valuable time. So thanks to all who do contribute and help. Ok so I will try to outline exactly what I did and where it fails. 1. I purchased a SSL certificate from GoDaddy to certify my single domain which for the sake of anonymity i will say www.example.com 2. I opened ISPConfig and went to my website listed for default user (only have 1 currently) 3. Under SSL I copied the SSL request and logged into GoDaddy and submitted that to them. 4. Selected Apache as the download option and received 2 files - www.example.com.crt and gd_bundle.crt 5. Under ISPConfig I pasted the contents of www.example.com.crt to the box under SSL request. Now my apache fails to restart. Under /var/log/ispconfig/httpd/example.com/error.log it lists these errors: [warn] RSA server certificate CommonName (CN) `www.example.com' does NOT match server name!? [Tue Jan 03 13:01:08 2012] [error] Unable to configure RSA server private key [Tue Jan 03 13:01:08 2012] [error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch The only way I can get Apache to start again is to comment out the SSL section in: /etc/apache/sites-available/example.com.vhost Then Apache restarts
Ok so an update I did what I said before but instead of choosing save I also added into the bundle section the contents of the gd_bundle.crt Now apache restarts but the log /var/log/ispconfig/httpd/example.com/error.log outputs a warning only that the Common Name doesn't match the server name. However when I try to access the website it still keeps a record of the old certificate that was self signed and certified. I don't know where it keeps this though.
Excellent, thanks for the detailed post. That makes it easy to help you. It sounds like you're simply using the wrong certificate components in the wrong places. The basic anatomy of a SSL certificate is: - .csr (Certificate Signing Request, which you created in ISPConfig interface) (belongs in "SSL Request" field within ISPC interface) - .crt (public certificate) (belongs in "SSL Certificate" field within ISPC interface) - .key (private key file; must remain protected) (is generated by ISPC when the CSR is created) - .bundle (CA chain; required to prevent authenticity warnings) (belongs in "SSL Bundle" field within ISPC interface) Note: The key and the certificate are sometimes combined into a single .pem file. All of the files are important, but based on your previous post, you seem to be missing the most important file of the bunch (the .key file). Or, you just didn't know where it was created or why it was important. Once the certificate has been issued, the .csr file serves no urgent purpose and can be ignored. The .key file and .crt files, however, are required. ISPConfig stores these files in a couple different locations: a.) ISPConfig's own "default" certificate components are stored in the following locations: Code: /usr/local/ispconfig/interface/ssl/ispserver.crt /usr/local/ispconfig/interface/ssl/ispserver.key Note: These are probably the certificates that Apache is continuing to use. b.) Each site's own certificate files, when managed with the ISPConfig interface, are stored in Code: /var/www/example.com/ssl The first thing you need to do is copy the GoDaddy-issued .crt and .bundle files to this location, and be sure the names follow the convention that ISPConfig expects, e.g.: Code: /var/www/example.com/ssl/example.com.crt /var/www/example.com/ssl/example.com.bundle You also need to ensure that the .key file is present (ISCP should have created it when you made the CSR via the ISPC interface): Code: /var/www/example.com/ssl/example.com.key When you restart Apache, your certificate should be used. Code: service apache2 restart At this point, there's really no need to paste the certificate parts into the ISPConfig interface. You will, however, have to ensure that the SSL box is checked for the website in question (it sounds as though that's already the case). Of course, you could paste the certificate contents into the ISPConfig interface and choose "Save certificate" for the SSL Action before clicking the Save button, which will copy the certificate contents into the database (and perhaps overwrite the files that you just copied to /var/www/example.com/ssl, which should be fine), but this step really isn't necessary unless you're OCD and want everything to be just-so in the ISPConfig interface (and there's nothing wrong with that). My point is simply that the risk is unnecessary in any sort of production environment. Any luck?
Quick thing I've noticed while i'm busy trying out your response (Thank you by the way) is that I don't get sent a .key from GoDaddy all I get is: www.example.com.crt gd_bundle.crt On their explanation of how to install a certificate into a apache environment is to find the .csr and .key on the server. My question is where do I find this .key that seems to be elusive. Thank you again
Please see my updated post above. I clarified several points in a subsequent edit. It's worth noting that ISPConfig overwrites various configuration files (including those relevant to Apache) when certain changes are initiated via the interface. Further, such overwriting occurs when Apache will not start after an interface-initiated change (ISPConfig attempts to roll-back to a previous, working configuration), which is why the old certificate keeps being restored to use. Not until a proper, functioning certificate is in-place will ISPConfig cease to perform these overwrite operations.
Ok I followed your post (thanks for the edit) and it still uses the old certificate. Self signed and verified by myself. I've restarted apache and the error log still lists the only error as Common Name not the same as the server name
What value do these thee directives have in /etc/apache2/sites-available/example.com.vhost: Code: SSLCertificateFile SSLCertificateKeyFile SSLCACertificateFile Also, what domain are you using when you try to access your site, example.com? If you are testing this all by reloading the ISPConfig interface, then you will continue to see the default certificate. If you want to use this certificate for the ISPConfig interface, you need to copy the .key and .crt files to the location that ISPConfig uses for its own certificates (see two posts ago).
There is no mention of: SSLCertificateFile SSLCertificateKeyFile SSLCACertificateFile in that file /etc/apache2/sites-available/example.com.vhost I have seen it in there before but currently there is nothing in there, I have also made sure that SSL is ticked on the website.
I connect using www.example.com which is the domain I registered with GoDaddy... In ISPConfig I have selected from the list instead of - example.com I choose www.example.com
Ok I might have fixed the problem... 1. I changed example.com.vhost to back.example.com.vhost 2. I ran /usr/local/ispconfig/server/server.sh 3. I restarted apache [/etc/init.d/apache2 restart] This made a new example.vhost which had the right lines in it. 4. I copied the www.example.com.crt and www.example.com.key and www.example.com.csr (don't think this is needed) to /usr/local/ispconfig/interface/ssl 5. Changed existing ispserver.(crt,key,csr) to back.ispserver.(crt,key,csr) 6. Changed www.example.com.(crt,key,csr) to ispserver.(crt,key,csr) 7. Restarted apache again [/etc/init.d/apache2 restart] So its seems to working fantastically... I will update if anything else goes wrong... Thank you, cbj4074 - don't know your name but thanks
Nice! Glad to hear it. Not sure exactly what got disconnected there, but it's academic at this point. You're welcome, holler if anything else comes up. Oh, and my name's Ben .
P.S., for help with configuring the /webmail URL, see this thread (and please post any questions about it there): http://www.howtoforge.com/forums/showthread.php?t=55590
Apparently its not fixed... I didn't notice anything wrong.. but my mate and my iPhone both came up with a warning message saying its untrusted. However I added into /etc/apache2/sites-available/ispconfig.vhost a line that said: SSLCertificateChainFile /usr/local/ispconfig/interface/ssl/gd_bundle.crt I have copied the gd_bundle.crt that I received to that location and restarted Aapache. however whenever I try to check with the GoDaddy installation tool it comes up with a error: "Results:SSL Connection Failed!" To summarize: 1. I have changed the one site that I have in ISPConfig to incorporate the signed certificate and the gd_bundle.crt (copied and pasted into ISPConfig under sites > www.example.com > Selected SSL > SSL Tab) 2. I have copied www.example.com and gd_bundle.crt to /usr/local/ispconfig/interfaces/ssl 3. Backed up original certificate and changed the names of the GoDaddy certificates to the ISPConfig self generated ones. 4. Edited /etc/apache2/sites-available/ispconfig.conf and inputted a line in the SSL enabled section: SSLCertificateChainFile /usr/local/ispconfig/interface/ssl/gd_bundle.crt 5. Restarted apache2 by doing a - "/etc/init.d/apache2 restart"
gd_bundle.crt should not be used for the SSLCertificateChainFile directive (it should be used for the SSLCACertificateFile). Please see: http://help.godaddy.com/article/5238