On Jul 12, 2011, at 9:35 PM, Jacob L. Leifman wrote:
>> FWIW, I'm guessing that the problem is at the router. The packet trace is
>> showing a TCP SYN coming from the client, followed correctly by a SYN-ACK
>> going back from the server. The client should send an ACK packet back, but
>> instead it
On 11 Jul 2011 at 20:59, Paul Suh wrote:
> On Jul 11, 2011, at 5:57 PM, Jacob L. Leifman wrote:
>
> > Environment:
> > - OpenBSD 4.9, stock (base) apache with self-signed certificate
> > - behind a SOHO NAT router (with relevant in-bound redirects)
> >
> > Problem: non-local SSL connections never
Hi Nigel,
The SSL certificate itself does not have any part in this problem as it
never gets that far in the process. As I wrote previously, the TCP
handshake never completes -- e.g. netstat & co. never see a connection
in any kind of state. I did try the suggested openssl command as well
as l
On Jul 11, 2011, at 5:57 PM, Jacob L. Leifman wrote:
> Environment:
> - OpenBSD 4.9, stock (base) apache with self-signed certificate
> - behind a SOHO NAT router (with relevant in-bound redirects)
>
> Problem: non-local SSL connections never complete the handshake
> (verified while monitoring the
Hi,
One guess would be the SSL certificate is for your internal hostname,
not your external hostname. Those connecting to the external hostname,
reject the connection because the hostname doesn't match the
certificate. To use both internal and external names you have to create
certificate und
Environment:
- OpenBSD 4.9, stock (base) apache with self-signed certificate
- behind a SOHO NAT router (with relevant in-bound redirects)
Problem: non-local SSL connections never complete the handshake
(verified while monitoring the interface with tcpdump, see below)
During troubleshooting I
6 matches
Mail list logo
