On Thu, May 14, 2009 at 3:17 PM, Neerav Singh <neerav.si...@tatatel.co.in> wrote: > Hi Ger > > Thanks a lot for the invaluable information, I opened my mind I had to read > a lot in order to get what you were suggesting, but worthwhile!! > > > > I tried a lot by setting different CFLAGS, got in the code, tried to find > some error, in the make file but with no help, everything was pointing to > the same ANSI problem > > Then finally we re-installed compiler and it worked like a magic, looks like > there was a problem with compiler installation.
Glad that got fixed. > Now I ran into another problem > > > > - I ran make command(openssl) successfully > > - Executed Configure for mod_ssl --- ./configure --with-apache… > --with-ssl=../openssl-… > > - Make certificate(DSA) > > - Configured apache with following options > --enable-rule=SHARED_CORE --enable-module=so --enable-module=ssl > --enable-shared=ssl --with-ssl…. > > - Then changed the port number in httpd.conf file to 8300 > > - Executed ./apachectl start > > - Executed ./apachectl startssl > > > > But when i connect to http://serverip:8300 I am able to see “The > SSL/TLS-aware Apache webserver was successfully installed on this website” > > > > How do I get HTTPS in the address is there any other port I need to access > or is there something more I need to do?? <scratches head> It's been quite a while since I messed with apache. Anyway, the issue is not quite clear from your description: can you get a HTTPS connection or not? (I assume not, or otherwise it wouldn't be stated as a problem, which means a 'don't' is missing from that last sentence, right? (And I've taken the liberty to adjust the subject line so others can see what this is about and respond in a better way than me at the moment.) There's a few bits and pieces to attend. I'll just write them down as they come up; think of it as an (incomplete) checklist: 1) first of all, HTTPS urls are at least https://<fqdn> or https://<fqdn>:<portnumber> where <fqdn> is a 'fully qualified domain name', e.g. 'code.google.com'. For HTTP, <fqdn> may be be a direct IP number (and it may as well for HTTPS, but there are a few nasty caveats then): The <fqdn> should match the server domain name specified in the previously generated and installed server certificate. 2) Then there's the wording 'server certificate': certificates have a purpose, which must be specified at certificate request generation time. server certificates are not client certificates are not email auth certificates are not ... etc. There's a lot of info on this in several places on the web and also in the history/archive of this mailing list as HTTPS server certificate related questions pop up quite often on this list. Depending on the server itself, such 'server certificates' must have particular attributes (OIDs) included. (Warning: this is off the top of my head and intentionally vague. I'd have to unearth my notes if this is [part of] the issue.) 3) Then there's server cert install and acceptability: self-signed certs can cause a hickup or two; depends on server and its setup 4) When server accepts/loads the cert, there's the default (standard) HTTPS port: 443. A quick 'nmap' port scan or other method to detect if the standard (or configured custom) port is open on the intended server interface can be useful as a _very shallow_ preliminary check. IIRC alternative port(s) for HTTPS can be set up in the mod_ssl config section of Apache. 5) When you've regular HTTP listening on port 8003, you cannot map the SSL port onto the same number as that would be a collision. Think of HTTP and HTTPS as two different servers in a single Apache package when it comes to interfaces, ports and virtual hosts (SSL doesn't work with virtual hosts when you want to present anywhere near a valid certificate for your HTTPS server, as SSL negotiation is performed before HTTPS request-embedded FQDN is mapped onto a virtual host. 6) Best to check the SSL connectivity with your server by trying to connect to it using openssl's own 's_client' utility (some web browsers are rather unhelpful when reporting trouble about HTTPS connection failures), once you've ensured the server is actually listening on the intended port (nmap or other portscanner tool; another crude way is telnet IP PORT, e.g. 'telnet 192.168.1.1 443' just to see if you're getting a IP connection; telnet doesn't talk SSL so it will fail immediately after you type something.). -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
