Roberto's picture


I am new to trunkey appliances, but a EC2 user for 4-5 years. I hope I can explain myself is a correct way.

I installed TK OwnCloud appliance 12.1 and had no problem with windows desktop client 1.41, then I installed did a EC2 new instance of Debian (wheezy) and installed OwnCloud by my self (5.012) and had no problems with the windows client. But when I installed the TK appliance 13.0rc I had problems with the windows desktop client.


"Server certificate was missing commonName Attribute....."


The TK appliance I did the update to 5.0.12, I have no idea if I am doing something wrong by updating, or if its just a bug that need to be taken care, it actualy says 13.0rc is in development. I even tryed to create my own sertificate thru webmin but still same problem.


Thanks to anyone that can point me to the right direction to solve the issue. 

bjorn's picture

After serching high and low, I found that i had to adapt into this that finally worked for me

cat > /root/regen-sslcert << 'EOF'

# Generate SSL certificate
# Note: daemons using certificate need to be restarted for changes to take effect

if [ $# -ne "0" ]; then

export C=""
export ST=""
export L=""
export O="TurnKey Linux"
export OU="Software appliances"
export CN="owncloud"
export emailAddress=""
export DAYS=3650
export BITS=1024
export KEYPASS="keyphrase" # workaround: no way of passing a blank pswd
export CERTFILE="/etc/ssl/certs/cert.pem"

if [ $HELP ]; then
    echo "Generate SSL certificate"
    echo "# VARIABLE      EXPLANATION          [VALUE]"
    echo "  C             Country Code         $C"
    echo "  ST            State or province    $ST"
    echo "  L             Locality (city)      $L"
    echo "  O             Organization name    $O"
    echo "  OU            Organizational unit  $OU"
    echo "  CN            Common name          $CN"
    echo "  emailAddress  Email address        $emailAddress"
    echo "  DAYS          Duration in days     $DAYS"
    echo "  BITS          RSA bits to use      $BITS"
    echo "  KEYPASS       Key password         $KEYPASS"
    echo "  CERTFILE      Output file          $CERTFILE"
    echo "# NOTES"
    echo "  Warning: only set password if you know what your doing"
    echo "  Display certificate: openssl x509 -text < $CERTFILE"
    exit 1


[ "$C"  ] && RDN="${RDN}C=${C}/"
[ "$ST" ] && RDN="${RDN}ST=${ST}/"
[ "$L"  ] && RDN="${RDN}L=${L}/"
[ "$O"  ] && RDN="${RDN}O=${O}/"
[ "$OU" ] && RDN="${RDN}OU=${OU}/"
[ "$CN" ] && RDN="${RDN}CN=${CN}/"
[ "$emailAddress" ] && RDN="${RDN}emailAddress=${emailAddress}/"

# create key and password protected cert
openssl req -x509 \
    -newkey rsa:$BITS \
    -keyout $TMPKEY -out $TMPCERT \
    -passout pass:$KEYPASS \
    -days $DAYS \
    -multivalue-rdn -subj "$RDN"

# remove password protection from key ---if not set by user
openssl rsa -passin pass:$KEYPASS < $TMPKEY > $CERTFILE

# add certificate to certificate file and set permissions
chmod 600 $CERTFILE

# cleanup

chmod +x /root/regen-sslcert
sh -xv /root/regen-sslcert
Roberto's picture


Thxs very much for pointing me to the right direction.

Got it fix now.


joe's picture

There is an error in the script.  It will just hang if you copy the script as is.

It hangs on the line "openssl req -x509 \" because the next line is a blank line instead

of the "-newkey rsa:$BITS \" line it expects.  This is because when the user posted the

code into the browser comment box the formatting inserted extra blank lines apparently.

The fix is to modify the above program and join these lines together like so without the extra blank lines in between:

openssl req -x509 \
-newkey rsa:$BITS \
-keyout $TMPKEY -out $TMPCERT \
-passout pass:$KEYPASS \
-days $DAYS \
-multivalue-rdn -subj "$RDN" 

I also recommend adding a "sh -xv /root/regen-sslcert" instead of "/root/regen-sslcert" to watch the program execute line by line (debug output) to make sure it works.  


Also, I needed to reboot the machine for the fix to take effect.



Jeremy Davis's picture

I have modified the above post as you suggested. Thanks again...

Also I have updated an old issue/bug about this problem and included a link back to this thread and the above post...

Chris's picture

Script did have an issue with the blanks lines as joe mentioned.

If you run bash -x regen-sslcert then it helps debug. i just restarted apache2 from init and it worked great.



Noid's picture

If your running this script but your servername (or FQDN) isn't "owncloud" change this line in the script so that it contains yours:

export CN="owncloud"

For example, if my servername was server01 it would be:

export CN="server01"


Would have saved me a lot of trouble!

John Carver's picture

while testing the ownCloud appliance for a possible application.  Couldn't figure out why it refused to sync until I googled the error message and found this thread.  Having just had to regenerate a bunch of ssl certs because of Heartbleed, it got me wondering if the 15regen-sslcert script could be made a little more intelligent by including the actual host name and domain name.  The startup scripts would have to be modified to prompt the user for host and domain or FDQN during first boot.  I would first make a dhcp request and use the values (if any) as the defaults, but allow the user to override them if desired.  I'm too busy right now to work on it, but if there is any interest I'd be willing to give it a go later in the year.

Information is free, knowledge is acquired, but wisdom is earned.

Jeremy Davis's picture

I think it's a nice idea, especially for the ownCloud appliance.

The only thing I'm not 100% sure about is the best way of doing it... Obviously the script needs to be able to run without interaction too, although I guess it could be done like the other inithooks that require input. Although for appliances that require the FQDN to be set, it'd be nice if the inithooks only asked once...

FWIW you can find the existing script in 'common' on GitHub.

nelson's picture

Im using the script you are reffering to in the github. But when I run "sh" i get this:


root@lamp ~# ./
Generating a 1024 bit RSA private key
writing new private key to '.tmpkey.pem'
writing RSA key


Am i missing something as this is not working... Still getting the error in owncloud.

John Carver's picture


The existing script on GitHub that Jeremy linked to is the original script that ran on first boot.  It generates a cert that won't work with OwnCloud because the CN is left blank.  I've patched the script to set CN=$(hostname) which satisfies OwnCloud.  I also changed the key length to 2048 which is now the minimum recommended RSA key length.

You can find my patched file at

I haven't submitted a pull request yet because I'm looking at some other changes and because I haven't fully tested a complete build.  Please try this version and let me know if there are any problems.

PS: The raw script file can be downloaded from

Information is free, knowledge is acquired, but wisdom is earned.

Alon Swartz's picture

Great work! We are gearing up for the 13.1 maintenance release, and I'd like to include both of your commits. I could merge manually, but would be great if you could send a pull request...

John Carver's picture

How soon do you need the pull request?  I started working on a script to query DNS for the hostname (rather than DHCP).  If a hostname is defined in DNS it uses that, otherwise it defaults to the appliance name (current behavior).  If you can wait a week or two, I'll try to finish the script and test it.

Information is free, knowledge is acquired, but wisdom is earned.

Jeremy Davis's picture

But I imagine that within the next couple of weeks should be fine! :)

Alon Swartz's picture

I propose we merge the current commits (2048 bits, hostname --fqdn), and then merge the enhanced version when its ready and tested.

John Carver's picture

Submitted pull request as you suggested.

Do you have any thoughts on the advisibility of setting the hostname using a reverse DNS query?  It works for me in my envirionment because I've setup a series of virtual hosts with fixed IP addresses and DNS names.  I'm concerned it might not work in all the other environments where TurnKey Linux is used.

The script I'm proposing would

  1. Determine the default interface from the routing table
  2. Determine the IP assigned to the default interface
  3. Do a host lookup of the IP and return the hostname or fdqn
  4. Apply the resulting name or default to the appliance name if null return

The script would run on firstboot before the ssl cert is generated so the correct name would be used in the certificate.

Information is free, knowledge is acquired, but wisdom is earned.

John Carver's picture

The instructions at don't explain what to do after the pull request has been generated and accepted.  I did get a suggestion that I should delete the branch and re-sync (? can't remember the exact message) with the upstream source.  I want to start a new branch and work on another issue, but I don't want to lose the changes I made so far.

# On branch master
nothing to commit (working directory clean)
root@tkldev-wheezy-amd64 fab/common# gll
* a2c14df - (HEAD, upstream/master, origin/master, origin/HEAD, master) bugfix:
* 0b82d79 - append user defined overlays/conf instead of pre
* b96285f - ninjux: added autokey (universal keyboard abbrevs) (6 months ago) <A
* 91e1fd4 - ninjux: fixed description of xbindkeys in autostart (6 months ago) <
* f3a010b - ninjux: moved 5 keybindings from WM to xbindkeys (less work customiz


# On branch update_regen_sslcert
nothing to commit (working directory clean)
root@tkldev-wheezy-amd64 fab/common# gll
* c1a5d18 - (HEAD, origin/update_regen_sslcert, update_regen_sslcert) changed ke
* 12f3b36 - add CN eq hostname or fqdn if available (2 months ago) <Dude4Linux>
* a2c14df - (upstream/master, origin/master, origin/HEAD, master) bugfix: GROUPS
* 0b82d79 - append user defined overlays/conf instead of pre
* b96285f - ninjux: added autokey (universal keyboard abbrevs) (6 months ago) <A
* 91e1fd4 - ninjux: fixed description of xbindkeys in autostart (6 months ago) <
* f3a010b - ninjux: moved 5 keybindings from WM to xbindkeys (less work customiz

Suggestions on how to proceed would be appreciated.


Information is free, knowledge is acquired, but wisdom is earned.

John Carver's picture

For future reference, I ran the following commands.

# Fetch any new changes to the original repository
git fetch upstream

# Merge any changes fetched into your working branch
git merge upstream/master

# Delete the local branch
git branch -d update_regen_sslcert

# Delete the remote branch
git push origin :update_regen_sslcert

# Update the remote master
git push origin


Information is free, knowledge is acquired, but wisdom is earned.

Liraz Siri's picture

For what it's worth it's possible to configure Git so that it automatically associates a local branch with a remote. That can simplify things somewhat.

Here's a script I use to register GitHub remotes so that I can pull or push from them with just one command:


progname=$(basename $(pwd|sed 's/\.git$//'))

if pwd | grep -q 'fab/products'; then
    set ${ACCOUNT:=turnkeylinux-apps}
    set ${ACCOUNT:=turnkeylinux}

if [ -z "$PROJECT" ]; then

if [ "$arg" == "-h" ] || [ "$arg" == "--help" ]; then
Syntax: $0
Environment variables:

    ACCOUNT         GitHub account name (default: $ACCOUNT)
    PROJECT         GitHub project name (default: $PROJECT)

What this does:

    git remote add -t master github$ACCOUNT/$PROJECT.git
    git config remote.github.push +master:refs/heads/master
    git config branch.master.remote github
    git.config branch.master.merge refs/heads/master

To remove:

    git-remote rm github

Update Github:

    git-push github


    exit 1

set -x

git remote add -t master github$ACCOUNT/$PROJECT.git
git config remote.github.push master:refs/heads/master
git config branch.master.remote github
git config branch.master.merge refs/heads/master
Jax's picture

hello , I also have this problem , I do not know how apply this script , please explain how to regenerate the certificate ,


ozidroid's picture

Whilst your solution got my OwnCloud Win Sync Client working, it has totally screwed me up in other ways.  Three steps fowards, two steps back.  Doubtless, I am doing something noobishly wrong.

Now, every time I reboot my TurnKey OwnCloud server it asks for the passphrase, or it won't complete the boot process.  By inspecting the script I decided the passphrase must be "<blank>" (literally, but without the quotes).  This got my server and sync client mostly working, but now I can't connect to any of the additional services such as:




Any illumination would help us all.


Jeremy Davis's picture

And I think that may solve your issue there (hopefully). As for the other thing about asking for a passphrase on boot, I'm not 100% sure about that one... I haven't come across that before, although TBH I haven't used ownCloud much either...

John Carver's picture

The original 15regen-sslcert script uses a crude hack to generate a cert without a password.  It first creates a certificate with a default password='<blank>'.  The default can be overridden by setting an environment variable (there may be cases where this is desired). It then checks, and if the default was not changed, it removes the password.  I didn't attempt to modify this part of the script since it has been working for a long time.  I modified only two lines to increase the key length to 2048 and to add the host name or fully qualified domain name to the certificate.

The proper way to download and run the script is:

bash -x 15regen-sslcert
service apache2 restart

If that still does not work, then check the value of the $KEYPASS environment variable to see if you have it set.

Note: The update_regen_sslcert branch has been deleted after the change was accepted into core, breaking the link above.  Use the link below instead.

Information is free, knowledge is acquired, but wisdom is earned.

Venks's picture

I have the same problem.  I am trying to fix it with your script but when I click on the link it says file not found.


Please give another link.  Thanks.


John Carver's picture

The git branch got deleted after Liraz accepted the change into core.  That broke the link and I didn't notice. The following link should work:

Information is free, knowledge is acquired, but wisdom is earned.

Venantius's picture

Thanks for updating the link.  I found another solution here -->

I changed from using .pem file to .crt and .key files.  After which it worked without a flaw.  I suppose this can be alternative solution.

Once again thank you for your response.


John Carver's picture

The .pem file is just a concatenation of the .crt and .key files.  I think it was setup this way because of shell-in-a-box, which wants a single file with both cert and key.  Shell-in-a-box is problematic in that it needs a valid, default cert/key file in order to start, but it then tends to generate it's own certs, one for each http header it encounters.  I tried generating a SAN (subject alternate name) cert, but it wouldn't recognize anything other than the Common Name.

I've been working on a more general approach for generating certs over at  I found the cert that was generated was accepted by the ownCloud client and by Firefox, but I've had problems getting Chrome, Chromium, and Safari to permanently recognize the cert as valid.  Have you noticed any issues with the cert/key you generated using the method you linked too?  If possible, could you check using one of the three browsers I mentioned and let me know if they will accept the cert permanently?  TIA

Information is free, knowledge is acquired, but wisdom is earned.

Add new comment