Forum

Hi there,

I have recently obtained an SSL certificate from GoDaddy and cannot get it to work. This is what I get when attempting to start Hiawatha:

Starting webserver: /etc/init.d/hiawatha: line 30:  6444 Segmentation fault      ${HIAWATHA}
error!

The CSR was generated following GoDaddy's instructions:

openssl genrsa -des3 -out server.key 2048
openssl req -new -key server.key -out serverkey.csr

The relevant section of my hiawatha.conf looks like this:

Binding {
        Port = 443
        SSLcertFile = /etc/hiawatha/serverkey.pem
}

Finally, this is what my serverkey.pem looks like (of course, I replaced the real data with BLABLABLA xD):

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,AE97D561AB8CB0FB

BLABLABLABLABLABLABLABLABLABLABLABLABLABLABLA...
-----END RSA PRIVATE KEY-----

-----BEGIN CERTIFICATE-----
BLABLABLABLABLABLABLABLABLABLABLABLABLABLABLA...
-----END CERTIFICATE-----

Having said that. PLEASE HELP!

Regards,
Tito

Hiawatha version: 7.3 (same problem with 7.2)
Operating System: Ubuntu 9.10

Please, follow these instrunctions.

Thanks, Hugo. This is the output from Valgrind:

==13539== Memcheck, a memory error detector
==13539== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==13539== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==13539== Command: ./hiawatha -c /home/tito/Desktop/hiawatha-7.3/http -d
==13539== 
==13539== Invalid read of size 1
==13539==    at 0x4026038: strlen (mc_replace_strmem.c:282)
==13539==    by 0x80561A6: password_callback (libssl.c:99)
==13539==    by 0x4195E96: PEM_do_header (in /lib/i686/cmov/libcrypto.so.0.9.8)
==13539==    by 0x4196413: PEM_bytes_read_bio (in /lib/i686/cmov/libcrypto.so.0.9.8)
==13539==    by 0x41997DE: PEM_read_bio_PrivateKey (in /lib/i686/cmov/libcrypto.so.0.9.8)
==13539==    by 0x40AA858: SSL_CTX_use_PrivateKey_file (in /lib/i686/cmov/libssl.so.0.9.8)
==13539==    by 0x8055F56: ssl_binding (libssl.c:176)
==13539==    by 0x80510BE: run_server (hiawatha.c:1845)
==13539==    by 0x8051A7C: main (hiawatha.c:2271)
==13539==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==13539== 
==13539== 
==13539== Process terminating with default action of signal 11 (SIGSEGV)
==13539==  Access not within mapped region at address 0x0
==13539==    at 0x4026038: strlen (mc_replace_strmem.c:282)
==13539==    by 0x80561A6: password_callback (libssl.c:99)
==13539==    by 0x4195E96: PEM_do_header (in /lib/i686/cmov/libcrypto.so.0.9.8)
==13539==    by 0x4196413: PEM_bytes_read_bio (in /lib/i686/cmov/libcrypto.so.0.9.8)
==13539==    by 0x41997DE: PEM_read_bio_PrivateKey (in /lib/i686/cmov/libcrypto.so.0.9.8)
==13539==    by 0x40AA858: SSL_CTX_use_PrivateKey_file (in /lib/i686/cmov/libssl.so.0.9.8)
==13539==    by 0x8055F56: ssl_binding (libssl.c:176)
==13539==    by 0x80510BE: run_server (hiawatha.c:1845)
==13539==    by 0x8051A7C: main (hiawatha.c:2271)
==13539==  If you believe this happened as a result of a stack
==13539==  overflow in your program's main thread (unlikely but
==13539==  possible), you can try to increase the size of the
==13539==  main thread stack using the --main-stacksize= flag.
==13539==  The main thread stack size used in this run was 8388608.
==13539== 
==13539== HEAP SUMMARY:
==13539==     in use at exit: 51,908 bytes in 2,557 blocks
==13539==   total heap usage: 2,768 allocs, 211 frees, 90,695 bytes allocated
==13539== 
==13539== 160 (40 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 217 of 276
==13539==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
==13539==    by 0x4479583: nss_parse_service_list (nsswitch.c:622)
==13539==    by 0x4479CC6: __nss_database_lookup (nsswitch.c:164)
==13539==    by 0x402CEAB: ???
==13539==    by 0x402DF84: ???
==13539==    by 0x4431D74: getpwnam_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253)
==13539==    by 0x44317DE: getpwnam (getXXbyYY.c:117)
==13539==    by 0x806350E: parse_userid (userconfig.c:34)
==13539==    by 0x805D9C0: read_main_configfile (serverconfig.c:931)
==13539==    by 0x8050F84: run_server (hiawatha.c:1813)
==13539==    by 0x8051A7C: main (hiawatha.c:2271)
==13539== 
==13539== 160 (40 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 218 of 276
==13539==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
==13539==    by 0x4479583: nss_parse_service_list (nsswitch.c:622)
==13539==    by 0x4479CC6: __nss_database_lookup (nsswitch.c:164)
==13539==    by 0x402BF2B: ???
==13539==    by 0x402CE34: ???
==13539==    by 0x447A3D1: __nss_getent_r (getnssent_r.c:171)
==13539==    by 0x44306C5: getgrent_r@@GLIBC_2.1.2 (getXXent_r.c:162)
==13539==    by 0x4479FCA: __nss_getent (getnssent.c:38)
==13539==    by 0x44300A9: getgrent (getXXent.c:84)
==13539==    by 0x80632A4: lookup_group_ids (userconfig.c:143)
==13539==    by 0x805DB3F: read_main_configfile (serverconfig.c:937)
==13539==    by 0x8050F84: run_server (hiawatha.c:1813)
==13539== 
==13539== LEAK SUMMARY:
==13539==    definitely lost: 80 bytes in 2 blocks
==13539==    indirectly lost: 240 bytes in 20 blocks
==13539==      possibly lost: 0 bytes in 0 blocks
==13539==    still reachable: 51,588 bytes in 2,535 blocks
==13539==         suppressed: 0 bytes in 0 blocks
==13539== Reachable blocks (those to which a pointer was found) are not shown.
==13539== To see them, rerun with: --leak-check=full --show-reachable=yes
==13539== 
==13539== For counts of detected and suppressed errors, rerun with: -v
==13539== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 39 from 10)

UPDATE: I have revoked the certificate and requested a new one. This time I avoided the -des3 option that GoDaddy shows in their help page and it worked.

Therefore, the instructions to request a certificate in GoDaddy that works with Hiawatha are:

openssl genrsa -out <name of your certificate>.key 2048
openssl req -new -key <name of your certificate>.key -out <name of your certificate>.csr

unlike what they show in this page: http://help.godaddy.com/topic/746/article/5269

I have also noticed that, when using DES3, the private key is preceded by these two lines:

Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,AE97D561AB8CB0FB

Perhaps that is not being handled correctly? Dunno, just a shot in the dark.

Tito

I had this problem and from your original post it looks like your private key was encrypted which I've found Hiawatha doesn't support but I can't think of any that do.

To decrypt an encrypted private key:

openssl rsa -in encryptedkey.pem -out unencryptedkey.pem

Sorry for the late response. It is true that Hiawatha does not support encrypted private keys. But of course, it shouldn't crash on it. I'll take a look at it when I have the time.