You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2008/12/31 15:13:31 UTC

DO NOT REPLY [Bug 46458] New: Allow dynamic generation of certificates.

https://issues.apache.org/bugzilla/show_bug.cgi?id=46458

           Summary: Allow dynamic generation of certificates.
           Product: Apache httpd-2
           Version: 2.2.11
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: mod_ssl
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: postmaster@sebn.us.to


I would suggest a enhancement to mod_ssl, allowing people to specify
SSLCertificateFile in this way:

SSLCertificateFile exec:/path/to/script/or/program

example:

SSLCertificateFile exec:/usr/bin/certgenerate %{SERVER_ADDR}
or
SSLCertificateFile exec:/usr/bin/certgenerate %{SERVER_PORT} %{SERVER_ADDR}
%{REMOTE_PORT} %{REMOTE_ADDR}

The intent is that the server administrator should be able to specify a script
or a program, that dynamically generates the certificate.
Of course all variables that is available prior SSL handshake should of course
be able to use in the SSLCertificateFile statement.

The script or program only needs to output the certificate on STDOUT and then
simply exit.

Example of uses, is for example a server administrator which have many IPs for
the same server, and then wants to give each IP number a own certificate
without having to create a VirtualHost for each IP.
By using a program, it would then be possible to fetch the correct certificate
based on the target IP of the request.

Another use would be the people who use Apache as either a forward proxy, or a
reverse proxy. The certgenerate software can then fetch the certificate from
the target IP by doing a SSL handshake with the IP, and then resigning the
certificate with a own CA key, and then priting the certificate on STDOUT.

This can for example be good for making a SSL scanning forward proxy, in
enviroments where security scanning of outgoing SSL traffic is required.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 46458] Allow dynamic generation of certificates.

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46458


sebastian <po...@sebn.us.to> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |




--- Comment #2 from sebastian <po...@sebn.us.to>  2009-01-02 09:50:29 PST ---
But I mean if I only know the hostname at the time of the request, before
SSL-handshake.

Or if I generate domains on-the-fly tied to a specific IP-adress, and want to
lookup the correct domain given a specific IP-adress, and then load the correct
certificate.

Lets say I have 50 IPs. Then lets say I have 50 different subdomains connected
to each IP.
Instead of creating 50 VirtualHosts with its own certificate, I could simply
have one virtualhost with SSLCertificateFile exec:/usr/bin/cat
/etc/httpd/certificates/%{SERVER_ADDR}.crt

And Apache would for the request with the target ip "213.12.14.56" execute
"/usr/bin/cat /etc/httpd/certificates/213.12.14.56.crt" (which would be a
certificate with its DN set to the correct domain)
and use the certificate it gets on STDOUT for the current SSL request.

Thats one example.

The following enviroment vars are available before handshake:
all SERVER_ variables
all REMOTE_ variables except REMOTE_USER
all TIME_ variables
and the HTTPS variable (which in this case always is "on")

Another example is in a corporate proxy situation, where you want to do SSL
scanning of all SSL requests made from inside firewall.
You can set up a DNS which delivers the IP 10.1.1.1 to 10.1.254.254
sequentally, for each domain requested, and then store which domain that was
requested when the IP x.x.x.x was returned, in a database...

So when a client with the IP 10.2.1.2 request:
www.google.se from the DNS, it would return "www.google.se IN A 10.1.1.1" , and
then store in database:
"UPDATE domaintable SET domain='www.google.se' WHERE ip='10.1.1.1' AND
clientip='10.2.1.2'"

next the same client request www.gmail.com, it would get "www.gmail.com IN A
10.1.1.2" from the DNS, and then it store:
"UPDATE domaintable SET domain='www.gmail.com' WHERE ip='10.1.1.2' AND
clientip='10.2.1.2'"

Then you can have a CA certificate with its corresponding private key, and then
have a normal certificate with a specific publickey and private key.

Then you can have:
SSLCertificateFile /usr/bin/certgenerate %{SERVER_ADDR} %{REMOTE_ADDR}

And the script could look something like this (pseudocode)
Get Argument1 and Argument2 from commandline
Variable1 = "SELECT domain FROM domaintable WHERE ip='Argument1' AND
clientip='Argument2'"
Load /etc/certificates/cert.pem
Replace current DN with Variable1
Resign certificate with the CA private key
print certificate on STDOUT

So this is the 2 examples I could come up with.

And I think this would be pretty easy to implement. The only thing that needs
to be changed, is to load the certificate for each request instead of server
start, and then allow the use of SSLCertificateFile exec:/path/to/program which
executes the program with specified arguments, and then reads from the STDOUT,
and a function to resolve variable names like %{REMOTE_ADDR}, %{SERVER_ADDR}
and such.

I think it would be a good interface to those that want to do some more
advanced certificate management than loading from a simple file.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 46458] Allow dynamic generation of certificates.

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46458


Joe Orton <jo...@redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #1 from Joe Orton <jo...@redhat.com>  2009-01-02 08:58:34 PST ---
1) if you know the set of hostnames which can be used ahead of time then you
can pregenerate the cert(s) and avoid having ugly hacks in mod_ssl.

2) if you don't know you'll need a wildcard cert anyway.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


DO NOT REPLY [Bug 46458] Allow dynamic generation of certificates.

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46458

Eric Covener <co...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #3 from Eric Covener <co...@gmail.com> 2011-08-07 00:24:19 UTC ---
Closing this enhancement request WONTFIX, too hairy and of limited usefulness. 
If you want to propose an interface in mod_ssl to make this possible outside of
mod_ssl, that is a possible alternative.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org