Guest User!

You are not Sophos Staff.

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

Site-to-Site with strongSwan x.509 cert issue

I'm trying to connect my ASG320 to a linux box running strongSWAN.  

In the cert manager I have created a cert named 20thstreet and setup the gateway/vpn deffinitions on my ASG320 using the IP of the remote strongSWAN box as the identifier. 

On my debian/strongSWAN box i have installed strongSWAN/openssl.  I imported the Astaro CA and running ipsec rereadall verifies that it's installed correctly.

 "gateway:/etc/ipsec.d/certs# ipsec listcacerts
000
000 List of X.509 CA Certificates:
000
000 Mar 09 14:21:03 2009, count: 1
000        subject:  and so on ................. "

On the ASG320 I exported the 20thstreet cert and put the pem file in /etc/ipsec.d/certs.   When I run ipsec rereadall I get
 "/etc/ipsec.secrets" line 10: syntax error in PKCS#1 private key file

I think i missed something but am not sure what.  Any input would be greatly appreciated.


This thread was automatically locked due to age.
Parents
  • The private key file that you defined in /etc/ipsec.secrets and which is stored in /etc/ipsec.d/private/ does not contain a private key in PKCS#1 format. The private key file content should be of the form

    -----BEGIN RSA PRIVATE KEY-----
    MIIEowIBAAKCAQEAr64uEJrApxtDe28anlGU0IXJmf4sjeEbJh8BbIjnNOsaZ2ex
    ...
    -----END RSA PRIVATE KEY-----

    without passphrase protection or

    -----BEGIN RSA PRIVATE KEY-----
    Proc-Type: 4,ENCRYPTED
    DEK-Info: DES-EDE3-CBC,1E1991A43D0778B7

    MAsd1YBlHz54KjvBvhpwDBewinBkxBo/NmdsMetLIcV8Ag87YcKtTXYju+fbW21y
    ...
    -----END RSA PRIVATE KEY-----

    with passphrase protection.

    Kind regards

    Andreas
Reply
  • The private key file that you defined in /etc/ipsec.secrets and which is stored in /etc/ipsec.d/private/ does not contain a private key in PKCS#1 format. The private key file content should be of the form

    -----BEGIN RSA PRIVATE KEY-----
    MIIEowIBAAKCAQEAr64uEJrApxtDe28anlGU0IXJmf4sjeEbJh8BbIjnNOsaZ2ex
    ...
    -----END RSA PRIVATE KEY-----

    without passphrase protection or

    -----BEGIN RSA PRIVATE KEY-----
    Proc-Type: 4,ENCRYPTED
    DEK-Info: DES-EDE3-CBC,1E1991A43D0778B7

    MAsd1YBlHz54KjvBvhpwDBewinBkxBo/NmdsMetLIcV8Ag87YcKtTXYju+fbW21y
    ...
    -----END RSA PRIVATE KEY-----

    with passphrase protection.

    Kind regards

    Andreas
Children
  • Thank you for your input, my next question is this, how do I convert the exported pem file from the astaro interface to the proper format, my only options are pkcs12 or pem.

    As a recap let me reiterate what I have on my remote strongswan box.

     /etc/ipsec.d/cacerts/myAstaroCA      

    /etc/ipsec.d/certs/selfSignedCertFromAstaroCA.pem

    Here are the contents of ipsec.secrets

    # RCSID $Id: ipsec.secrets.proto,v 1.3.6.1 2005/09/28 13:59:14 paul Exp $
    # This file holds shared secrets or RSA private keys for inter-Pluto
    # authentication.  See ipsec_pluto(8) manpage, and HTML documentation.

    # RSA private key for this host, authenticating it to any other host
    # which knows the public part.  Suitable public keys, for ipsec.conf, DNS,
    # or configuration of other implementations, can be extracted conveniently
    # with "ipsec showhostkey".
    #: RSA /etc/ipsec.d/private/bellRd-gatewayKey.pem
    : RSA /etc/ipsec.d/certs/test.pem  This file is from astaroCA











    Here are the contents of the pem file

    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number:
                9a:c5:e1:89:03:33:0e:18
            Signature Algorithm: md5WithRSAEncryption
            Issuer: C=us, L=Phoenix, O=Medical Services Inc., CN=Medical Services Inc. VPN CA/emailAddress=dmarkwith@Mysite.com
            Validity
                Not Before: Mar  9 23:06:22 2009 GMT
                Not After : Mar 28 21:44:28 2035
            Subject: C=us, ST=Az, L=Phoenix, O=Medical Services Inc., OU=IT, CN=bellRd-gateway.Mysite.com/emailAddress=skeys@MySite.com
            Subject Public Key Info:
                Public Key Algorithm: rsaEncryption
                RSA Public Key: (2048 bit)
                    Modulus (2048 bit):
                        00:a8:97:67:e9:18:21:e5:52:07:c1:53[[[:D]]]4:1a:07:
                        12:79:2e:80[[[:D]]]0:1d:47:6d:e9:c0:42:68:a9:54:69:
                        ec:10:9d:97:3a:c4[[[:D]]]e[[[:D]]]b:f2:0b:09:ae:b3:62:e1:
                        00:13:bf:94:07[[[:D]]]3:2b:cd:b3[[[:D]]]3:65:16:89:89:e1:
                        48:57:16:a5:02:7a:f9:6f:ba:bc:1b:b0:06:30:23:
                        10:62:4d:94:fe:4b:b6:f1:88:81:cd:0e:47:33:6f:
                        87:02:e9:3e:12:5e:fc:39:25:4e:6d:e5:7b:e3:7e:
                        12[[[:D]]]d:65:98:67:7d:3d:88:8a:fb:7f:57:37:01:9a:
                        22:c9:9c[[[:D]]]d:50:93:c8:46:5b[[[:D]]]8[[[:D]]]1[[[:D]]]f:8f:4e:a2:
                        ce:21:bf:05:36:7c:6f:0d:26:e1:09:bc:a0:11:92:
                        94:2c:2a:98:f6:7f:45:af:46:7f:88:e9:a1:aa:6a:
                        c2:1f:f9:3e:cd:10:4d:2f:6a:f2:5a:f6:74:8f:c6:
                        23:61:e1:cc:aa:e7:ac:99:9b:75:91:88:39:3c:34:
                        1f:27:69:f6:6b:c7:7a:fe:a6:9a:ae:b6:cf:9c:51:
                        dc:b0:1f:7f:13:4e:a4:96:7f:72:89:7b:91:90:17:
                        98:c6:5e:26:69:bb:03:06:e9:a8:39:2b:02:ae:01:
                        3c:7e:ab:25:0b:0a:73:78:fd:c1:72:29:b9:47:27:
                        4d:69
                    Exponent: 65537 (0x10001)
            X509v3 extensions:
                X509v3 Subject Key Identifier: 
                    84:07:A7:95:5C:04:F5:AA[[:D]]9:F4:34:CA:ED:2F:45:41:51:4A:48:3F
                X509v3 Authority Key Identifier: 
                    keyid:EE[[:D]]E:8E:EB:93:25:30:E7:CC:C6:18:3B:C6:EF:EE:08:90:A5:27:67
                    DirName:/C=us/L=Phoenix/O=Medical Services Inc./CN=Medical Services Inc. VPN CA/emailAddress=dmarkwith@Mysite.com
                    serial:9A:C5:E1:89:03:33:0E:0E

                X509v3 Subject Alternative Name: 
                    IP Address:77.77.165.73
                X509v3 Basic Constraints: 
                    CA:FALSE
                X509v3 Key Usage: 
                    Digital Signature, Non Repudiation, Key Encipherment
        Signature Algorithm: md5WithRSAEncryption
            15:f6[[[:D]]]2:eb:39:83:a1:7a:6c:43:4e:45:b7:8d:26:48:06:6e:
            da:1d:a0:f4:47:43:ab[[[:D]]]8:5e:0c:24:81:8f:48:49:62:18:2e:
            be:09:a5:25:e3[[[:D]]]b:e2:e8:37[[[:D]]]1:90:4b:03:a5[[[:D]]]d:56:fc:b1:
            ad:74:ad:9d:52:09:bb:70:1f:5c:c4:c6:4f:1e[[[:D]]]4[[[:D]]]b:f9:ec:
            21:40:50:c0:63:0e:62:04:ee:0e:b5:f0:8f:91:07:5b:c8:5a:
            c0:10:8e:4f:cb:71:f0:32[[[:D]]]6:73:fb:a5:c4:cf:ae:5e:cf:bf:
            33:53:e7:c4:3f:14:ea:a2:16:5e:c3:ce:88[[[:D]]]e:a6:ab:c3:10:
            9d:23
    -----BEGIN CERTIFICATE-----
    MIIEUDCCA7mgAwIBAgIJAJrF4YkDMw4YMA0GCSqGSIb3DQEBBAUAMIGQMQswCQYD
    VQQGEwJ1czEQMA4GA1UEBxMHUGhvZW5peDEgMB4GA1UEChMXUGh5c2ljaWFuIFNl
    cnZpY2VzIEluYy4xJzAlBgNVBAMTHlBoeXNpY2lhbiBTZXJ2aWNlcyBJbmMuIFZQ
    TiBDQTEkMCIGCSqGSIb3DQEJARYVZG1hcmt3aXRoQHBzaXNpdGUuY29tMCIXDTA5
    MDMwOTIzMDYyMloXETM1MDMyODIxNDQyOCswMDAwMIGiMQswCQYDVQQGEwJ1czEL
    MAkGA1UECBMCQXoxEDAOBgNVBAcTB1Bob2VuaXgxIDAeBgNVBAoTF1BoeXNpY2lh
    biBTZXJ2aWNlcyBJbmMuMQswCQYDVQQLEwJJVDEjMCEGA1UEAxMaYmVsbFJkLWdh
    dGV3YXkucHNpc2l0ZS5jb20xIDAeBgkqhkiG9w0BCQEWEXNrZXlzQHBzaXNpdGUu
    Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqJdn6Rgh5VIHwVPU
    GgcSeS6A0B1HbenAQmipVGnsEJ2XOsTe2/ILCa6zYuEAE7+UB9MrzbPTZRaJieFI
    VxalAnr5b7q8G7AGMCMQYk2U/ku28YiBzQ5HM2+HAuk+El78OSVObeV7434S3WWY
    Z309iIr7f1c3AZoiyZzdUJPIRlvY0d+PTqLOIb8FNnxvDSbhCbygEZKULCqY9n9F
    r0Z/iOmhqmrCH/k+zRBNL2ryWvZ0j8YjYeHMquesmZt1kYg5PDQfJ2n2a8d6/qaa
    rrbPnFHcsB9/E06kln9yiXuRkBeYxl4mabsDBumoOSsCrgE8fqslCwpzeP3Bcim5
    RydNaQIDAQABo4IBFDCCARAwHQYDVR0OBBYEFIQHp5VcBPWq2fQ0yu0vRUFRSkg/
    MIHFBgNVHSMEgb0wgbqAFO7ejuuTJTDnzMYYO8bv7giQpSdnoYGWpIGTMIGQMQsw
    CQYDVQQGEwJ1czEQMA4GA1UEBxMHUGhvZW5peDEgMB4GA1UEChMXUGh5c2ljaWFu
    IFNlcnZpY2VzIEluYy4xJzAlBgNVBAMTHlBoeXNpY2lhbiBTZXJ2aWNlcyBJbmMu
    IFZQTiBDQTEkMCIGCSqGSIb3DQEJARYVZG1hcmt3aXRoQHBzaXNpdGUuY29tggkA
    msXhiQMzDg4wDwYDVR0RBAgwBocEP/2lSTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF
    4DANBgkqhkiG9w0BAQQFAAOBgQAV9tLrOYOhemxDTkW3jSZIBm7aHaD0R0Or2F4M
    JIGPSEliGC6+CaUl49vi6DfRkEsDpd1W/LGtdK2dUgm7cB9cxMZPHtTb+ewhQFDA
    Yw5iBO4OtfCPkQdbyFrAEI5Py3HwMtZz+6XEz65ez78zU+fEPxTqohZew86I3qar
    wxCdIw==
    -----END CERTIFICATE-----

    I'm willing to paypal someone $50usd(i know it isnt much) who can help me get this working.
  • It looks to me like you asked about certs and Andreas wrote about your "private key file."  Since he's the creator of StrongSWAN, I suspect his approach works.  If StrongSWAN can handle certs, then you apparently need to change its configuration.

    Cheers - Bob
  • > ipsec rereadall
    002 forgetting secrets
    002 loading secrets from "/etc/ipsec.secrets"
    002   loaded private key file '/etc/ipsec.d/private/bellRd-gatewayKey.pem' (1675 bytes)  
    002 Changing to directory '/etc/ipsec.d/cacerts'
    002   loaded CA cert file 'astaroCA.pem' (3156 bytes)
    002 Changing to directory '/etc/ipsec.d/aacerts'
    002 Changing to directory '/etc/ipsec.d/ocspcerts'
    002 Changing to directory '/etc/ipsec.d/acerts'
    002 Changing to directory '/etc/ipsec.d/crls'

    I changed ipsec.secrets so that it was to read the self-generated pem file, not the key generated by the astaroCA and I dont get any errors.  

    > ipsec auto --add main
    > ipsec auto --up main
    104 "main" #1: STATE_MAIN_I1: initiate
    003 "main" #1: ignoring Vendor ID payload [2d1f406118fbd5d28474791ffa00488a]
    003 "main" #1: ignoring Vendor ID payload [Cisco-Unity]
    003 "main" #1: ignoring Vendor ID payload [XAUTH]
    003 "main" #1: received Vendor ID payload [Dead Peer Detection]
    106 "main" #1: STATE_MAIN_I2: sent MI2, expecting MR2
    003 "main" #1: unable to locate my private key for RSA Signature
    224 "main" #1: STATE_MAIN_I2: AUTHENTICATION_FAILED
    010 "main" #1: STATE_MAIN_I2: retransmission; will wait 20s for response
    003 "main" #1: unable to locate my private key for RSA Signature
    224 "main" #1: STATE_MAIN_I2: AUTHENTICATION_FAILED
    003 "main" #1: unable to locate my private key for RSA Signature
    224 "main" #1: STATE_MAIN_I2: AUTHENTICATION_FAILED
    010 "main" #1: STATE_MAIN_I2: retransmission; will wait 40s for response
    031 "main" #1: max number of retransmissions (2) reached STATE_MAIN_I2
    000 "main" #1: starting keying attempt 2 of an unlimited number, but releasing whack

    I did something wrong or missed a step and it has to do with certs.
  • Recap  this is what I did on ASG320.

    1. Created a cert for my remote gateway
    2. Setup a gateway/vpn connection using that cert 

    Recap of what I did on my debian box running strongSWAN

    1. Imported the ASG320 CA to /etc/ipsec.d/cacerts/ASG320.pem
    2. Imported the cert generated from ASG320 to /etc/ipsec.d/certs/remoteGateway.pem
    3. Created a vpn connection using remoteGateway.pem for the leftcert

    Is that correct or did I miss something?
  • Recap  this is what I did on ASG320.

    1. Created a cert for my remote gateway
    2. Setup a gateway/vpn connection using that cert 

    Recap of what I did on my debian box running strongSWAN

    1. Imported the ASG320 CA to /etc/ipsec.d/cacerts/ASG320.pem
    2. Imported the cert generated from ASG320 to /etc/ipsec.d/certs/remoteGateway.pem
    3. Created a vpn connection using remoteGateway.pem for the leftcert

    Is that correct or did I miss something?


    #2 on my debain box I imported the cert but not the key file 

    openssl pkcs12 *clcerts  *nodes *nokeys *in /certs/client.p12 *out client.pem
    openssl pkcs12  *nodes *nocerts *in /certs/client.p12 *out client.key

    and added the appropriate entry in ipsec.secrets

    Now I'm getting this error 
    ignoring informational payload, type INVALID_ID_INFORMATION 

    but I think this error has to do with the VPN ID in the cert.

    A simple Simon mistake as I suspected [:)]
  • Yes,  the ID that you define on the debian box with leftid= must match the peer identity that you define on the ASG320. If leftid= is missing then the subject distinguished name extracted from the certificate loaded via leftcert= is used.

    Regards

    Andreas
  • Thanks again, I must be getting close but I still get INVALID_ID_INFORMAION with this config 

    conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyingtries=1
    left=my strongSwan public IP
    leftcert=bell.pem
    leftid=@my strongSwan public IP
    # leftfirewall=yes

    conn net-net
    leftsubnet=10.1.0.0/16
    right=my astaro public IP
    rightsubnet=10.2.0.0/16
    rightid=@my astaro public IP

    both my CN and VPNID are set to their respected public IP addresses.  If I drop the @ before my ip identifiers I get "no valid key known for "my astaro public IP" on the linux box.  Do I need to do something with the key astaro is using?  I thought all I needed to do was add the astaroCA to my strongSwan remote box.

    Thanks in advance.
  • If you are using an ID_IPV4_ADDR as an identity then you *must not* prepend a @ character since this notation is used for Fully-Qualified Domain Names! The IP address must be included as a SubjectAltName in the X.509 certificate which was the case at least for the cert you posted earlier:

    X509v3 Subject Alternative Name:
    IP Address:77.77.165.73

    The error "no valid key known for "my astaro public IP" is a strong  indication that a matching SubjectAltName is missing in the cert sent by the Astaro box.

    Andreas
  • Andreas thanks a bunch, VPN established. One more question from my network behind the astaro I'm able to reach any machine that is behind the debian/strongSwan box, but NOT able to go from machines on my network behind debian/strongSwan to machines behind the astaro.  I did some searching and played around with nexthop, but no luck, ip_forward is enabled.  I didn't see any type of ipsec interface on my debian/strongSwan side.  I have also tried leftfirewall=yes .

    Route table dump from astaro 

    172.16.1.0      *               255.255.255.0   U     0      0        0 eth2
    172.17.0.0      *               255.255.255.0   U     0      0        0 eth6
    192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
    192.168.5.0     *               255.255.255.0   U     0      0        0 ipsec0

    Route table dump from debian/strongSwan

    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    192.168.5.0     *                   255.255.255.0   U      0      0        0 eth2
    192.168.0.0     AstaroPubIP 255.255.255.0   UG    0      0        0 eth1
    PubNetworkAddr    *                  255.255.255.0   U      0      0        0 eth1
    default            ISPPubIP       0.0.0.0             UG    0      0        0 eth1

    Config file from debian/strongSwan


    conn %default
    ikelifetime=60m
    keylife=20m
    rekeymargin=3m
    keyingtries=1
    left=pubIP
    leftcert=bell.pem
    leftid=pubIP
    leftfirewall=no
    leftsubnet=192.168.5.0/24

    conn net-net
    auth=esp
    esp=aes-128-md5
    right=pubIP
    rightsubnet=192.168.0.0/24
    rightid=pubIP
    rightcert=AstaroHost.pem
    auto=start


    Again thanks, you have gone above and beyond.  Also please PM me your paypal address so I can send your $.

    Thanks,
    Sean
  • If MASQUERADING is activated on your debian box then you must exempt traffic to be tunnelled from NAT by inserting the following iptables rule in the POSTROUTING chain:

    iptables -t nat -I POSTROUTING 1 -s 192.168.5.0/24 -o eth1 -m policy --dir out --pol ipsec --proto esp -j ACCEPT

    Andreas