# [solved] HTTPS help

## BlueFusion

I installed my first purchased SSL certificate today.  I've dabbled around with self-signed for years.  I have installed it and it appears to work server-side with NameVirtualHost on :80 and :443.

This is what I get whenever I use curl on the host server or any system on the network (including over VPN).

```
supernova htdocs # curl https://localhost --insecure      ## Self-signed certificate, so --insecure is necessary

<html><body><h1>It works!</h1></body></html>              ## default virtualhost page

supernova ~ # curl https://newkindofcool.com

SSL works!                                                ## my https virtualhost docroot page
```

But when I try from anywhere outside of my network, past my NAT router (DD-WRT), I get this:

```
rich@area51 ~ $ curl https://newkindofcool.com

curl: (60) SSL certificate problem: self signed certificate

More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"

 of Certificate Authority (CA) public keys (CA certs). If the default

 bundle file isn't adequate, you can specify an alternate file

 using the --cacert option.

If this HTTPS server uses a certificate signed by a CA represented in

 the bundle, the certificate verification probably failed due to a

 problem with the certificate (it might be expired, or the name might

 not match the domain name in the URL).

If you'd like to turn off curl's verification of the certificate, use

 the -k (or --insecure) option.

rich@area51 ~ $ curl https://newkindofcool.com --insecure

curl: (52) Empty reply from server
```

I have TCP port 443 forwarded through my DD-WRT NAT router.  I don't understand why it can get certificate information and then nothing else.  Can someone help me figure out what is going on, please?

----------

## BlueFusion

I have disabled the default SSL vhost as well but with the same results.

You can try yourself.  Use the domain:

https://newkindofcool.com (should load the same data as http://newkindofcool.com now)

and the IP address:

https://99.153.28.241 (should load same as http://99.153.28.241)

Here's my DD-WRT port forward table:

http://newkindofcool.com/dd-wrt-settings.jpg

Here are the configuration files:

```
supernova vhosts.d # cat 00_default_ssl_vhost.conf 

<IfDefine SSL>

<IfDefine SSL_DEFAULT_VHOST>

<IfModule ssl_module>

# see bug #178966 why this is in here

# When we also provide SSL we have to listen to the HTTPS port

# Note: Configurations that use IPv6 but not IPv4-mapped addresses need two

# Listen directives: "Listen [::]:443" and "Listen 0.0.0.0:443"

Listen 443

NameVirtualHost *:443

<VirtualHost *:443>

        ServerName localhost

        Include /etc/apache2/vhosts.d/default_vhost.include

        ErrorLog /var/log/apache2/ssl_error_log

        <IfModule log_config_module>

                TransferLog /var/log/apache2/ssl_access_log

        </IfModule>

        ## SSL Engine Switch:

        # Enable/Disable SSL for this virtual host.

        SSLEngine on

        ## SSL Cipher Suite:

        # List the ciphers that the client is permitted to negotiate.

        # See the mod_ssl documentation for a complete list.

        SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

        ## Server Certificate:

        # Point SSLCertificateFile at a PEM encoded certificate. If the certificate

        # is encrypted, then you will be prompted for a pass phrase. Note that a 

        # kill -HUP will prompt again. Keep in mind that if you have both an RSA

        # and a DSA certificate you can configure both in parallel (to also allow

        # the use of DSA ciphers, etc.)

        SSLCertificateFile /etc/ssl/apache2/server.crt

        ## Server Private Key:

        # If the key is not combined with the certificate, use this directive to

        # point at the key file. Keep in mind that if you've both a RSA and a DSA

        # private key you can configure both in parallel (to also allow the use of

        # DSA ciphers, etc.)

        SSLCertificateKeyFile /etc/ssl/apache2/server.key

        ## Server Certificate Chain:

        # Point SSLCertificateChainFile at a file containing the concatenation of 

        # PEM encoded CA certificates which form the certificate chain for the

        # server certificate. Alternatively the referenced file can be the same as

        # SSLCertificateFile when the CA certificates are directly appended to the

        # server certificate for convinience.

        #SSLCertificateChainFile /etc/ssl/apache2/ca.crt

        ## Certificate Authority (CA):

        # Set the CA certificate verification path where to find CA certificates

        # for client authentication or alternatively one huge file containing all

        # of them (file must be PEM encoded).

        # Note: Inside SSLCACertificatePath you need hash symlinks to point to the

        # certificate files. Use the provided Makefile to update the hash symlinks

        # after changes.

        #SSLCACertificatePath /etc/ssl/apache2/ssl.crt

        #SSLCACertificateFile /etc/ssl/apache2/ca-bundle.crt

        ## Certificate Revocation Lists (CRL):

        # Set the CA revocation path where to find CA CRLs for client authentication

        # or alternatively one huge file containing all of them (file must be PEM 

        # encoded).

        # Note: Inside SSLCARevocationPath you need hash symlinks to point to the

        # certificate files. Use the provided Makefile to update the hash symlinks

        # after changes.

        #SSLCARevocationPath /etc/ssl/apache2/ssl.crl

        #SSLCARevocationFile /etc/ssl/apache2/ca-bundle.crl

        ## Client Authentication (Type):

        # Client certificate verification type and depth. Types are none, optional,

        # require and optional_no_ca. Depth is a number which specifies how deeply

        # to verify the certificate issuer chain before deciding the certificate is

        # not valid.

        #SSLVerifyClient require

        #SSLVerifyDepth  10

        ## Access Control:

        # With SSLRequire you can do per-directory access control based on arbitrary

        # complex boolean expressions containing server variable checks and other

        # lookup directives. The syntax is a mixture between C and Perl. See the

        # mod_ssl documentation for more details.

        #<Location />

        #       #SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \

        #       and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \

        #       and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \

        #       and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \

        #       and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20       ) \

        #       or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/

        #</Location>

        ## SSL Engine Options:

        # Set various options for the SSL engine.

        ## FakeBasicAuth:

        # Translate the client X.509 into a Basic Authorisation. This means that the

        # standard Auth/DBMAuth methods can be used for access control. The user 

        # name is the `one line' version of the client's X.509 certificate. 

        # Note that no password is obtained from the user. Every entry in the user 

        # file needs this password: `xxj31ZMTZzkVA'.

        ## ExportCertData:

        # This exports two additional environment variables: SSL_CLIENT_CERT and 

        # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the server

        # (always existing) and the client (only existing when client 

        # authentication is used). This can be used to import the certificates into

        # CGI scripts.

        ## StdEnvVars:

        # This exports the standard SSL/TLS related `SSL_*' environment variables. 

        # Per default this exportation is switched off for performance reasons, 

        # because the extraction step is an expensive operation and is usually 

        # useless for serving static content. So one usually enables the exportation

        # for CGI and SSI requests only.

        ## StrictRequire:

        # This denies access when "SSLRequireSSL" or "SSLRequire" applied even under

        # a "Satisfy any" situation, i.e. when it applies access is denied and no

        # other module can change it.

        ## OptRenegotiate:

        # This enables optimized SSL connection renegotiation handling when SSL 

        # directives are used in per-directory context.

        #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire

        <FilesMatch "\.(cgi|shtml|phtml|php)$">

                SSLOptions +StdEnvVars

        </FilesMatch>

        <Directory "/var/www/localhost/cgi-bin">

                SSLOptions +StdEnvVars

        </Directory>

        ## SSL Protocol Adjustments:

        # The safe and default but still SSL/TLS standard compliant shutdown

        # approach is that mod_ssl sends the close notify alert but doesn't wait

        # for the close notify alert from client. When you need a different

        # shutdown approach you can use one of the following variables:

        ## ssl-unclean-shutdown:

        # This forces an unclean shutdown when the connection is closed, i.e. no

        # SSL close notify alert is send or allowed to received.  This violates the

        # SSL/TLS standard but is needed for some brain-dead browsers. Use this when

        # you receive I/O errors because of the standard approach where mod_ssl

        # sends the close notify alert.

        ## ssl-accurate-shutdown:

        # This forces an accurate shutdown when the connection is closed, i.e. a

        # SSL close notify alert is send and mod_ssl waits for the close notify

        # alert of the client. This is 100% SSL/TLS standard compliant, but in

        # practice often causes hanging connections with brain-dead browsers. Use

        # this only for browsers where you know that their SSL implementation works

        # correctly. 

        # Notice: Most problems of broken clients are also related to the HTTP 

        # keep-alive facility, so you usually additionally want to disable 

        # keep-alive for those clients, too. Use variable "nokeepalive" for this.

        # Similarly, one has to force some clients to use HTTP/1.0 to workaround

        # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and

        # "force-response-1.0" for this.

        <IfModule setenvif_module>

                BrowserMatch ".*MSIE.*" \

                        nokeepalive ssl-unclean-shutdown \

                        downgrade-1.0 force-response-1.0

        </IfModule>

        ## Per-Server Logging:

        # The home of a custom SSL log file. Use this when you want a compact 

        # non-error SSL logfile on a virtual host basis.

        <IfModule log_config_module>

                CustomLog /var/log/apache2/ssl_request_log \

                        "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

        </IfModule>

</VirtualHost>

</IfModule>

</IfDefine>

</IfDefine>

# vim: ts=4 filetype=apache
```

```
supernova vhosts.d # cat newkindofcool.com.conf    

<VirtualHost *:80>

        ServerName newkindofcool.com

        ServerAlias www.newkindofcool.com

        ServerAdmin webmaster@newkindofcool.com

        DocumentRoot "/home/ashbo/htdocs"

        <Directory "/home/ashbo/htdocs">

                Options Indexes FollowSymLinks

                AllowOverride All

                        Order allow,deny

                        Allow from all

        </Directory>

        <IfModule alias_module>

                ScriptAlias /cgi-bin/ "/home/ashbo/cgi-bin/"

        </IfModule>

        <Directory "/home/ashbo/cgi-bin">

                AllowOverride None

                Options None

                Order allow,deny

                Allow from all

        </Directory>

        <IfModule mpm_peruser_module>

                ServerEnvironment apache apache

        </IfModule>

</VirtualHost>

<IfDefine SSL>

<IfDefine SSL_DEFAULT_VHOST>

<IfModule ssl_module>

<VirtualHost *:443>

        ServerName newkindofcool.com

        ServerAlias www.newkindofcool.com

        ErrorLog /var/log/apache2/ssl_error_log

        ServerAdmin webmaster@newkindofcool.com

        DocumentRoot "/home/ashbo/htdocs"

        <Directory "/home/ashbo/htdocs">

                Options Indexes FollowSymLinks

                AllowOverride All

                Order allow,deny

                Allow from all

        </Directory>

        <IfModule alias_module>

                ScriptAlias /cgi-bin/ "/home/ashbo/cgi-bin/"

        </IfModule>

        <Directory "/home/ashbo/cgi-bin">

                AllowOverride None

                Options None

                Order allow,deny

                Allow from all

        </Directory>

        <IfModule log_config_module>

                TransferLog /var/log/apache2/ssl_access_log

        </IfModule>

        SSLEngine on

        SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

        SSLCertificateFile /etc/ssl/apache2/newkindofcool.com.crt

        SSLCertificateKeyFile /etc/ssl/apache2/newkindofcool.com.key

        SSLCertificateChainFile /etc/ssl/apache2/newkindofcool.com.ca-bundle

        <FilesMatch "\.(cgi|shtml|phtml|php)$">

                SSLOptions +StdEnvVars

        </FilesMatch>

        <Directory "/home/ashbo/cgi-bin">

                SSLOptions +StdEnvVars

        </Directory>

        <IfModule setenvif_module>

                BrowserMatch ".*MSIE.*" \

                        nokeepalive ssl-unclean-shutdown \

                        downgrade-1.0 force-response-1.0

        </IfModule>

        <IfModule log_config_module>

                CustomLog /var/log/apache2/ssl_request_log \

                        "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

        </IfModule>

</VirtualHost>

</IfModule>

</IfDefine>

</IfDefine>

# vim: ts=4 filetype=apache
```

----------

## BlueFusion

Some further information.  I installed tcpdump on my server and watched the incoming traffic on port 443.

When I access it over the VPN, packets flow without issue:   (note: 10.1.1.1 is the router which is also the VPN server, which is why it appears the traffic is coming from there)

 *Quote:*   

> supernova ~ # tcpdump -i eth0 port 443
> 
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> 
> listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
> ...

 

When I try the same curl request from an external source, not over VPN, not a single packet makes it to the server, according to tcpdump.

Okay, well then I logged into telnet on my router to verify that it is infact forwarding https to 10.1.1.15 (supernova).  It is as it should be.

iptables on my firewall:

```
root@orbit:~# iptables -L -n

Chain INPUT (policy ACCEPT)

target     prot opt source               destination         

ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           

ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 

ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:1723 

ACCEPT     47   --  0.0.0.0/0            0.0.0.0/0           

DROP       udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:520 

DROP       udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:520 

ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:520 

logaccept  tcp  --  0.0.0.0/0            10.1.1.1            tcp dpt:80 

logaccept  tcp  --  0.0.0.0/0            10.1.1.1            tcp dpt:23 

DROP       icmp --  0.0.0.0/0            0.0.0.0/0           

DROP       2    --  0.0.0.0/0            0.0.0.0/0           

ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           state NEW 

logaccept  0    --  0.0.0.0/0            0.0.0.0/0           state NEW 

DROP       0    --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination         

ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           

TCPMSS     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU 

ACCEPT     47   --  10.1.1.0/24          0.0.0.0/0           

ACCEPT     tcp  --  10.1.1.0/24          0.0.0.0/0           tcp dpt:1723 

ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           

TCPMSS     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU 

lan2wan    0    --  0.0.0.0/0            0.0.0.0/0           

ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 

ACCEPT     tcp  --  0.0.0.0/0            10.1.1.15           tcp dpt:80 

ACCEPT     tcp  --  0.0.0.0/0            10.1.1.15           tcp dpt:443 

ACCEPT     tcp  --  0.0.0.0/0            10.1.1.15           tcp dpt:21 

ACCEPT     tcp  --  0.0.0.0/0            10.1.1.254          tcp dpt:1792 

ACCEPT     udp  --  0.0.0.0/0            10.1.1.254          udp dpt:1792 

TRIGGER    0    --  0.0.0.0/0            0.0.0.0/0           TRIGGER type:in match:0 relate:0 

trigger_out  0    --  0.0.0.0/0            0.0.0.0/0           

ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0           state NEW 

DROP       0    --  0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination
```

Okay, so maybe there's a service on port 443 listening on the router?

 *Quote:*   

> root@orbit:~# netstat -an
> 
> Active Internet connections (servers and established)
> 
> Proto Recv-Q Send-Q Local Address           Foreign Address         State       
> ...

 

Nope, nothing is listening on port 443.

So I guess afterall, this is not an Apache/SSL issue.  It appears to me to be something more network related.

Where the hell is this certificate coming from and where the hell are the packets going????

FWIW, and you can check this yourself, nmap is reporting that https is open as it should be.  I don't believe my ISP is blocking it in any way, they claim not to block any ports (AT&T U-verse).

----------

## BlueFusion

A further update......

I found out how to get tcpdump working on my router.

It shows no activity when it comes to sending HTTPS data to is via the WAN to be forwarded.  There's plenty of HTTPS data passing through as there are android clients and other devices constantly checking https websites.  Not a darn thing relating to my requests, though.

Does this make sense to anybody?  Any tips?  What else should I check?

----------

## BlueFusion

Well my continuous devotion into the problem paid off.

Apparently it IS my ISP.  It's not an intentional port block.  If you have AT&T U-Verse and use a wireless AP for the set-top-boxes, it uses port 443 for a VPN tunnel.  It has no ability to select a different port, unfortunately.

Time to buy some IP addresses :\

----------

