Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 1 subscriber
  • Views 13494 views
  • Users 0 members are here
Options
Suggested
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

Will regenerating CA void the user's SSL VPN certificates?

ppadler
Good morning everyone,
So I have the problem described here (iOS5 refusing Cisco VPN client connection to ASG 8.202), obviously because the VPN CA certificate presented in 

Remote Access -> Certificate Management -> Certificate Authority 


has only a 1024 bit modulus. iOS5 seems to require that to be 2048 bits long (as well as having only SHA1 fingerprints instead of MD5 but we already fulfill that requirement).

Now the only way out seems to be regenerating the CA cert. I can do that from the "Advanced" tab.:

Here you can regenerate the VPN signing CA that was created during the initial setup of the unit. The VPN signing CA is the certificate authority with which digital certificates are signed that are used for remote access and site-to-site VPN connections. To ensure that VPN connections that use the old VPN signing CA are still working after the exchange of the signing CA, the old VPN signing CA will be kept as verification CA.

Caution! The device and all user certificates will be regenerated with the new signing CA. This may break current Site-to-Site VPN and Roadwarrior connections.

 (emphasize mine)

The two parts in bold seem to contradict each other.

We have several SSL-VPN-Users (OpenVPN) that rely on this connection. Will their ability to connect break once I regenerate the CA and until they re-download their configuration from the VPN user portal?

-- Paul


This thread was automatically locked due to age.
  • 0
    Hi, Paul, and welcome to the User BB!

    I think the warning is about IPsec site-to-site, not Remote Access SSL VPN, so your users don't need to reload if you don't reconfigure it.

    Even if you have an existing IPsec site-to-site, it seems like keeping the prior CA should avoid the bolded warning.

    Cheers - Bob
    PS I did a related post in the beta section where it will be seen by the developers: https://community.sophos.com/products/unified-threat-management/astaroorg/f/112/t/71310
  • 0
    Hi Bob, thanks for your answer. I gave it a shot and - failed:

    Tue Nov 22 17:03:35 2011 TCPv4_CLIENT link local: [undef]
    Tue Nov 22 17:03:35 2011 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: /C=de/L=xx/O=xx/CN=xx/emailAddress=xx
    Tue Nov 22 17:03:35 2011 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
    Tue Nov 22 17:03:35 2011 TLS Error: TLS object -> incoming plaintext read error
    Tue Nov 22 17:03:35 2011 TLS Error: TLS handshake failed
    Tue Nov 22 17:03:35 2011 Fatal TLS error (check_tls_errors_co), restarting
    Tue Nov 22 17:03:35 2011 TCP/UDP: Closing socket
    Tue Nov 22 17:03:35 2011 SIGUSR1[soft,tls-error] received, process restarting
    Tue Nov 22 17:03:35 2011 Restart pause, 5 second(s)

    Using the update-installer from the User Portal I reinstalled the configuration package on a client and it at least now works again.
    Now I'll clear some time in my calendar for user help requests...
    --Paul
  • 0
    And you didn't change the 'Server certificate' on the 'Advanced' tab of SSL?  I don't understand why that should happen.  Thanks for trying it.

    Cheers - Bob
  • 0
    Hi All, 

    if you regenerate the CA than all Certificates generated by the old CA are no longer valid. 
    You should only use this in very rare cases if you are able to restart your userbase.

    Gert
  • 0 in reply to Gert Hansen
    Hi Gert,

    if you regenerate the CA than all Certificates generated by the old CA are no longer valid. 

    So why does it keep the old CA as a Verification CA then? (and announces that old certificates can still be verified that way)

    You should only use this in very rare cases if you are able to restart your userbase.

    Well "restarting" means helping all SSL VPN users download their updates configuration in my case.

    What's even worse: Regenerating the CA yielded a new CA certificate but that still has 1024bit length!
    I was under the impression that regenerating would yield a 2048bit CA. And that seems to be one of the two requirements for iOS5 VPN connections.

    I don't even know how to get a 2048bit CA.

    Can anybody shed some light on this? I a somewhat disappointed that forcing all SSL VPN users to redownload their config did not even help me. [:(]

    -- Paul
  • 0 in reply to BAlfson
    And you didn't change the 'Server certificate' on the 'Advanced' tab of SSL?  I don't understand why that should happen.  Thanks for trying it.

    Didn't answer that yet:
    I personally did not do anything in the SSL page. But now if I look at it, the CA-regeneration seems to have changed the
    Remote Access -> SSL -> Adanced -> Server Certificate
    to "Local X509 Cert (regenerated)".

    So I suggest a warning to the CA regeneration text that the SSL VPN Server certificate will be changed and therefore any client cofiguration will break until redownload.

    If anyone has an idea for how I can get the iOS-compatible 2048bit CA certificate generated, that would be real helpful.

    Thanks for all the help, Paul
  • 0
    @ppadler: What happens if you change the cert on the SSL 'Advanced' tab back to the old one?

    @Gert: Are you sure there isn't more you should say about that?

    Cheers - Bob
  • 0 in reply to BAlfson
    Bob,
    @ppadler: What happens if you change the cert on the SSL 'Advanced' tab back to the old one?

    I could not try that. The experience of having everyone download their SSL VPN configuration once was bad enough that I won't touch that configuration if not totally necessary, sorry.

    Thanks for your help!

    -- Paul