Adding Certificates

Archived from groups: comp.security.firewalls (More info?)

Can certificates be added to a firewall Running Checkpoint NG 55
without configuring the firewall? I would like to add certificates to
a firewall, but I don't want to configure the firewall (IP Addresses,
netmasks, hostname, etc. etc.)

Thanks!
5
answers
Last reply
More about adding certificates
  1. Archived from groups: comp.security.firewalls (More info?)

    The question is...what is a certificate's main function?

    The answer is...to uniquely identify the bearer of the certificate

    The problem is...I would like to add certificates to
    a firewall, but I don't want to configure the firewall

    The answer is...No, Your identity (online) is tied to your IP address, if
    you change your IP address, you will need to renew your certificates. If you
    do not provide an IP address, you have not satisfied the requirement, having
    an IP address, which is needed to certify the source, your identity.

    "Pedro Cortez" <nomada7@hotmail.com> wrote in message
    news:db72fc7c.0405260732.e2cd802@posting.google.com...
    > Can certificates be added to a firewall Running Checkpoint NG 55
    > without configuring the firewall? I would like to add certificates to
    > a firewall, but I don't want to configure the firewall (IP Addresses,
    > netmasks, hostname, etc. etc.)
    >
    > Thanks!


    ---
    Outgoing mail is certified Virus Free.
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.688 / Virus Database: 449 - Release Date: 5/18/2004
  2. Archived from groups: comp.security.firewalls (More info?)

    "Beoweolf" <Beoweolf@pacbell.net> writes:
    > The question is...what is a certificate's main function?
    >
    > The answer is...to uniquely identify the bearer of the certificate
    >
    > The problem is...I would like to add certificates to
    > a firewall, but I don't want to configure the firewall
    >
    > The answer is...No, Your identity (online) is tied to your IP address, if
    > you change your IP address, you will need to renew your certificates. If you
    > do not provide an IP address, you have not satisfied the requirement, having
    > an IP address, which is needed to certify the source, your identity.


    basically a certificate is to bind some information to a public key,
    typically for use in an offline environment.

    typically somebody generates a digital signature, appends a certificate
    and transmits it.

    the receiver eventually gets the transmission, uses the certificae to
    verify the digital signature and then has some comfort that the
    transmission is somehow related to the information bound in the
    certificate. the type of information bound in the certificate might be
    identity or even permission related.

    the typical business process has the receiver looking up some online
    account record for the information instead of with a certificate.

    certificates had a design point from the early '80s for offline email
    .... the environment where somebody dialed up their "post office",
    exchange email, hung up and processed the email offline. the
    certificate was designed to serve an introductory function when the
    recipient had never previously had any communication with the sender.

    the function of the certificate was to serve as a substitute, in an
    offline electronic environment of the early 80s, for access to the
    real information. In a firewall scenario ... the lack of RADIUS-like
    function being able to access the real information.

    the x.509 identity certificate standards (somewaht from the early 90s)
    started to run into problems by the mid-90s because of the enourmous
    privacy issues related to having potentially enourmous amounts of
    privacy related information flying around in such certificates.

    Somewhat in an attempt to preserve the certificate paradigm and
    demonstrate some marginal utility for certificates ... there was some
    effort to retrench the x.509 identity certificate to something called
    a relying-party-only certificate ... which basically contained only an
    account number and a public key. Some financial operations
    demonstrated such an implementation in conjunction with various
    payment related operations.

    There was some serious issues with this mode of operation.

    1) it was trivial to show that in such a relying-party-only
    scenario; the certificate was redundant and superfluous. by definition
    if you have to access the account record with all the real
    information, then the certificate doesn't actually contain any useful
    information, making the existance of the certificate redundant and
    superfluous. it also violates the basic assumptions of the certificate
    design point, a substitute in an offline environment for access to the
    real information.

    2) even relying-party-only certificates could get to fairly large,
    nominally in the 4kbyte to 12kbyte range. in the payment attachment
    scenario; the typical payment message is 60-80 bytes, containing the
    account number and the amount of the transaction. In the
    relying-party-only scenario a 128byte digital signature would be
    attached to the payment message followed by the digital certificate.
    This is sent to the relying-party financial institution that has all
    the information in an account record (including a copy of a public
    key). The destination financial institution pulls the account number
    from the payment transaction, reads the account record, retrieves the
    public key and verifies the digital signature. At no time did it need
    to resort to referencing the certificate. So in an attempt to
    demonstrate some marginally utility for a relying-party-only
    certificate, append a certificate that need never be used but does
    increase the payload bloat of a typical payment message by
    approximately one hundred times.

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
  3. Archived from groups: comp.security.firewalls (More info?)

    Mailman <mailman@anonymous.org> writes:

    > I don't know where you got that idea, but it just doesn't work that
    > way.
    >
    > A certificate is a third party confirmation of your NAME, not your
    > address. Thus a server certificate (which is probably what the OP
    > was asking about) simply confirms that the server www.serv.com
    > really is www.serv.com. What the IP address is has nothing to do
    > with this: that is the job of the DNS.
    >
    > Look up the definition of the certificate fields for X509.
    >
    > As to "adding certificates to the firewall" - the question is
    > meaningless. A firewall has no certificates, nor does it use them. A
    > certificate is almost always connected to an application (Web
    > server, EMail server, proxy, browser, EMail client, VPN, etc), so
    > you need to look for the documentation for those. -- Mailman

    domain name server certificates exist because of trust issues with the
    domain name system and am I really talking to the server I think that
    I'm talking to.

    basically 3rd party certificatation authority is asked to certify that
    i'm really the owner of the domain name and issue a certificate to
    that effect.

    the client types or clicks on a URL ... the browser goes off and
    contacts the server, the server sends back a certificate ... the
    browser checks to see if it is a valid certificate (using a table of
    certification authority public keys that have somehow been loaded into
    the browser at some time) and then checks to see if the domain name in
    the certificate matches the typed or clicked on value. so one of the
    exploits is to get the user to click on a field that actually points
    to a domain name that matches a certificate that a bad guy might
    happen to have.

    now, the 3rd party certification authorities ... in order to certify
    somebody is really the domain name owner ... have to contact the
    authoritative agency for domain name ownership; which turns out to be
    the domain name infrastructure ... this is the same entity that people
    supposedly have trust issues with and therefor believe they need
    certificates.

    now, 3rd party certificate authorities have some trust issues and
    process issues with domain name infrastructure also ... there happen
    to be a number of proposals to improve the integrity of the domain
    name infrastructure ... some of them being backed by the 3rd party CAs
    (if people can't trust the source of the information for the certified
    infomration, how can they trust the certificate).

    one of these proposals somewhat from the 3rd party CA industry,
    involve a domain name owner registering a public key with the domain
    name infrastructure at the same time they register their domain name.
    Future interaction between the domain name owner and the domain name
    infrastructure can involve digital signatures that can be validated
    with the registered public key ... minimizing things like domain name
    hijacking and various other exploits. So this improves the reliance
    and trust that the 3rd party CA industry places in the domain name
    infrastructure.

    the other issue is that the 3rd party certification process is fairly
    expensive identification process. the current paradigm has the domain
    name owner registering a bunch of identity information with the domain
    name infrastructure. when the domain name owner applies for their
    server certificate, they also provide a lot of identification
    information. The 3rd party CA than has an expensive and error prone
    process matching the presented identification information with the
    identification information on file with the domain name
    infrastructure. With a public key on file with the domain name
    infrastructure, the domain name owner can just digitally sign a
    certificate request. the 3rd party CA then just has to retrieve the
    public key on file and verify the digital signature. This changes an
    expensive and error prone identification process into a much simpler,
    less error prone, and less expensive authentication process.

    So there is something of a catch22 for the 3rd party certification
    industry.

    1) If the integrity of the domain name infrastructure is improved,
    then the lack of trust supposedly will be lowered, which likely also
    results in lower demand for certificates.

    2) if there is a public key on file with the domain name
    infrastructure (for the domain name owner) that the 3rd party
    certification process can retrieve for authentication ... then
    presumably other entities, like end-users and clients might also be
    able to retrieve the public key for performing authentication
    .... eliminating the requirement for needing digital certificates
    issued by a 3rd party certification authorities.

    misc. past posts on ssl server certificates
    http://www.garlic.com/~lynn/subtopic.html#sslcert

    note that general case of using the domain name infrastructure for a
    public key server (w/o needing certificates) shows up in some of the
    anti-spam proposals for authenticating email senders.

    part of the issue is that that the domain name infrastructure is
    actually a distributed, near-real-time, information distribution
    mechanism. it is currently primarily used to distribute the ip-address
    related to a specific domain or host name. however, the domain name
    infrastructure has also been used for serving up other kinds of
    real-time data. There is nothing that prevents the domain name
    infrastructure from also serving up real-time public keys that are
    bound to a domain or host name.

    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
  4. Archived from groups: comp.security.firewalls (More info?)

    Beoweolf wrote:

    > The question is...what is a certificate's main function?
    >
    > The answer is...to uniquely identify the bearer of the certificate
    >
    > The problem is...I would like to add certificates to
    > a firewall, but I don't want to configure the firewall
    >
    > The answer is...No, Your identity (online) is tied to your IP address, if
    > you change your IP address, you will need to renew your certificates. If
    > you do not provide an IP address, you have not satisfied the requirement,
    > having
    > an IP address, which is needed to certify the source, your identity.

    I don't know where you got that idea, but it just doesn't work that way.

    A certificate is a third party confirmation of your NAME, not your address.
    Thus a server certificate (which is probably what the OP was asking about)
    simply confirms that the server www.serv.com really is www.serv.com. What
    the IP address is has nothing to do with this: that is the job of the DNS.

    Look up the definition of the certificate fields for X509.

    As to "adding certificates to the firewall" - the question is meaningless. A
    firewall has no certificates, nor does it use them. A certificate is almost
    always connected to an application (Web server, EMail server, proxy,
    browser, EMail client, VPN, etc), so you need to look for the documentation
    for those.
    --
    Mailman
  5. Archived from groups: comp.security.firewalls (More info?)

    Mailman (mailman@anonymous.org) wrote:
    : Beoweolf wrote:

    : > The question is...what is a certificate's main function?
    : >
    : > The answer is...to uniquely identify the bearer of the certificate
    : >
    : > The problem is...I would like to add certificates to
    : > a firewall, but I don't want to configure the firewall
    : >
    : > The answer is...No, Your identity (online) is tied to your IP address, if
    : > you change your IP address, you will need to renew your certificates. If
    : > you do not provide an IP address, you have not satisfied the requirement,
    : > having
    : > an IP address, which is needed to certify the source, your identity.

    : I don't know where you got that idea, but it just doesn't work that way.

    : A certificate is a third party confirmation of your NAME, not your address.
    : Thus a server certificate (which is probably what the OP was asking about)
    : simply confirms that the server www.serv.com really is www.serv.com. What
    : the IP address is has nothing to do with this: that is the job of the DNS.

    : Look up the definition of the certificate fields for X509.

    : As to "adding certificates to the firewall" - the question is meaningless. A
    : firewall has no certificates, nor does it use them. A certificate is almost
    : always connected to an application (Web server, EMail server, proxy,
    : browser, EMail client, VPN, etc), so you need to look for the documentation
    : for those.
    : --
    : Mailman

    In the context of the original question it is not meaningless. In the Checkpoint
    arena the management server also functions as a certificate authority for enforcement
    modules. A checkpoint firewall most certainly does have certificates and makes
    extensive use of them. The firewall will not function with the cert.

    Now, the original question asked was could one add certificates to a checkpoint firewall
    without configuring it. The answer is no. The certificate is created when the firewall
    object is created and the internal communications tab is press. At that time you have to
    enter a one-time password that will be used to download the certificate. In order to
    have the process start, the firewall object must be configured so the extent that it
    has a name and at least one interface is routable from the enforcement module and the
    management server. You do not have to fully configure the interfaces ro anything
    else on it.

    You then use cpconfig on the enforcement module to reset SIC and enter the same one time
    password. If both sides can see each other [the default policy loaded on the enforcement
    module has the UDP port used for SIC open] they will use the one time password to validate
    each other and the managment server will push the certificate for the enforcement module
    down to it. When that happens, SIC is running and uses the certificate to verify the
    connection. The cert is not tied to IP but to the name of the firewall object and the
    name of the management server object. If either of these change, you have to re-initialize
    SIC on both sides [which revokes the old certificate].

    Richard H. Miller, MCSE, CCSE+
    Information Security Manager
    Information Technology Security and Compliance
    Information Technology - Baylor College of Medicine
Ask a new question

Read More

Firewalls Configuration Security Networking