This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Revoke certificate CR

Hi,
how I can revoke users certicates  build into CA Management ?
Now I can delete , sign , download as PER  DEM PCKS12
format .

ASL-5.026 

Thank You


This thread was automatically locked due to age.
Parents
  • bodyman,

    I do not see the necessity to revoke certs issued by a selfcreated Astaro SA because noone trusts their certs but you. Simply remove the certificate from the vpn connections and it will be useless anyway.

    The only intension of Astaro certs is to authenticate against vpn.

    But for full X.509 compliance it wouldn't be bad to have the possibility to revoke a cert instead of deleting it.

    Greetings
    cyclops
  • [ QUOTE ]
    bodyman,

    I do not see the necessity to revoke certs issued by a selfcreated Astaro SA because noone trusts their certs but you. Simply remove the certificate from the vpn connections and it will be useless anyway.

    The only intension of Astaro certs is to authenticate against vpn.

    But for full X.509 compliance it wouldn't be bad to have the possibility to revoke a cert instead of deleting it.

    Greetings
    cyclops 

    [/ QUOTE ]

    I'm afraid this isn't true if you're using the IPSec authentication by CA, i.e. everybody that has a certificate signed by the CA can establish a connection. It does not matter if anyone else trusts the CA. Removing the cert from the list doesn't revoke its right to establish a connection - only a CRL can do that. However, if you're using the built in CA management, there's no easy way to create a CRL and to revoke someone's access if needed when using a CA-based connection. Deleting certificates only works for simple Roadwarrior connections, not for Roadwarrior CA.

    Using CA-based authentication is a nice thing because a) it works without any additional software on Windows 2000/XP and b) it doesn't require a client-specific configuration: For letting a new user in, you only have to create the certificate/key, sign it with the CA and hand it to the user together with a simple config file and a few simple instructions. Nothing else to configure, neither for the user nor on the FW.

    If Astaro is offering built-in CA management, it should do it completely, not just half the way.


    BTW: There is a, though non-trivial way to create a CRL by using OpenSSL with the CA certificate: (tested with Cygwin)

    1. Download the CA certificate in PEM format and extract the .zip file.

    2. Prepare OpenSSL to use the CA (demoCA is the default name that is found in OpenSSL's config file. It can be changed, but you don't have to). "CERT_myca.pem" and "KEY_myca.pem" are the files extracted from the downloaded zip file.
     Code:
    $ mkdir demoCA
    $ touch demoCA/index.txt
    $ echo "01" > demoCA/serial
    #
    # Inititialize
    $ openssl ca -cert CERT_myca.pem -keyfile KEY_myca.pem



    3. Revoke the certificate(s). 
    Code:
    $ openssl ca -cert CERT_myca.pem -keyfile KEY_myca.pem -revoke CERTIFICATE_baduser.pem



    4. Generate the CRL file in PEM format. This should produce a CRL that can be uploaded to Astaro.
    Code:
    $ openssl ca -cert CERT_myca.pem -keyfile KEY_myca.pem -gencrl > mycrl.pem



    Repeat step 3 and 4 as often as you need to. There are also some options you can set for the CRL generation, such as next update date, etc. but this is optional.

    HTH,
    Sascha
Reply
  • [ QUOTE ]
    bodyman,

    I do not see the necessity to revoke certs issued by a selfcreated Astaro SA because noone trusts their certs but you. Simply remove the certificate from the vpn connections and it will be useless anyway.

    The only intension of Astaro certs is to authenticate against vpn.

    But for full X.509 compliance it wouldn't be bad to have the possibility to revoke a cert instead of deleting it.

    Greetings
    cyclops 

    [/ QUOTE ]

    I'm afraid this isn't true if you're using the IPSec authentication by CA, i.e. everybody that has a certificate signed by the CA can establish a connection. It does not matter if anyone else trusts the CA. Removing the cert from the list doesn't revoke its right to establish a connection - only a CRL can do that. However, if you're using the built in CA management, there's no easy way to create a CRL and to revoke someone's access if needed when using a CA-based connection. Deleting certificates only works for simple Roadwarrior connections, not for Roadwarrior CA.

    Using CA-based authentication is a nice thing because a) it works without any additional software on Windows 2000/XP and b) it doesn't require a client-specific configuration: For letting a new user in, you only have to create the certificate/key, sign it with the CA and hand it to the user together with a simple config file and a few simple instructions. Nothing else to configure, neither for the user nor on the FW.

    If Astaro is offering built-in CA management, it should do it completely, not just half the way.


    BTW: There is a, though non-trivial way to create a CRL by using OpenSSL with the CA certificate: (tested with Cygwin)

    1. Download the CA certificate in PEM format and extract the .zip file.

    2. Prepare OpenSSL to use the CA (demoCA is the default name that is found in OpenSSL's config file. It can be changed, but you don't have to). "CERT_myca.pem" and "KEY_myca.pem" are the files extracted from the downloaded zip file.
     Code:
    $ mkdir demoCA
    $ touch demoCA/index.txt
    $ echo "01" > demoCA/serial
    #
    # Inititialize
    $ openssl ca -cert CERT_myca.pem -keyfile KEY_myca.pem



    3. Revoke the certificate(s). 
    Code:
    $ openssl ca -cert CERT_myca.pem -keyfile KEY_myca.pem -revoke CERTIFICATE_baduser.pem



    4. Generate the CRL file in PEM format. This should produce a CRL that can be uploaded to Astaro.
    Code:
    $ openssl ca -cert CERT_myca.pem -keyfile KEY_myca.pem -gencrl > mycrl.pem



    Repeat step 3 and 4 as often as you need to. There are also some options you can set for the CRL generation, such as next update date, etc. but this is optional.

    HTH,
    Sascha
Children
No Data