Roberto's picture
Roberto - Mon, 2013/10/14 - 23:31

Hi

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. 

Forum: 
Support
Tags: 
owncloud
Roberto's picture

Roberto - Mon, 2013/11/04 - 07:06

Bjorn,

Thxs very much for pointing me to the right direction.

Got it fix now.

cheers!

Jeremy Davis's picture

Jeremy Davis - Sun, 2014/02/02 - 13:28

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...

John Carver's picture

John Carver - Thu, 2014/04/24 - 05:54

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

Jeremy Davis - Thu, 2014/04/24 - 14:10

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.

John Carver's picture

John Carver - Wed, 2014/05/14 - 16:37

Nelson,

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 https://github.com/Dude4Linux/common/blob/update_regen_sslcert/overlays/...

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 https://raw.githubusercontent.com/Dude4Linux/common/update_regen_sslcert...

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

Alon Swartz's picture

Alon Swartz - Tue, 2014/05/27 - 14:38

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

John Carver - Wed, 2014/05/28 - 01:48

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

Jeremy Davis - Wed, 2014/05/28 - 03:11

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

Alon Swartz's picture

Alon Swartz - Wed, 2014/05/28 - 10:41

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

John Carver - Wed, 2014/05/28 - 17:58

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

John Carver - Mon, 2014/07/07 - 17:38

The instructions at https://github.com/turnkeylinux-apps/tkldev/blob/master/docs/development... 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 - turnkey-desktop.mk: 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 - turnkey-desktop.mk: 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

John Carver - Tue, 2014/07/08 - 07:01

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

Liraz Siri - Thu, 2014/07/10 - 01:20

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:

#!/bin/bash

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

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

if [ -z "$PROJECT" ]; then
    PROJECT=$progname
fi

if [ "$arg" == "-h" ] || [ "$arg" == "--help" ]; then
cat<<EOF
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 git@github.com:$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
    git-remote rm github

Update Github:

    git-push github

EOF

    exit 1
fi

set -x

git remote add -t master github git@github.com:$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
Jeremy Davis's picture

Jeremy Davis - Wed, 2014/07/02 - 13:27

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

John Carver - Tue, 2014/10/21 - 23:28

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:

wget https://raw.githubusercontent.com/Dude4Linux/common/update_regen_sslcert/overlays/turnkey.d/sslcert/usr/lib/inithooks/firstboot.d/15regen-sslcert
...
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.

https://raw.githubusercontent.com/Dude4Linux/common/master/overlays/turn...

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

John Carver's picture

John Carver - Tue, 2014/10/21 - 23:22

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:

https://raw.githubusercontent.com/Dude4Linux/common/master/overlays/turn...

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

John Carver's picture

John Carver - Wed, 2014/10/22 - 18:40

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 https://github.com/Dude4Linux/common/tree/create-ssl-cert-with-subject-a....  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