VPN works with keys, not with certificates

[melodien]

I have an ongoing problem with getting a route based site to site VPN going between 2 Juniper firewalls.  It works if I use preshared keys, but not if I used certificates.  Attached is a diagram which decribes the scenario.  I have two outbound interfaces, with addresses on different networks.  115.70.21.250 resolves as stockade.testlogistics.com, and I have a Verisign certificate installed for that FQDN.  If I connect a laptop directly to the firewall and point a browser at that FQDN, the certificate is accepted with no problems (if I try the IP address I get the certificate warning that you would expect).  However, from the remote firewall (203.45.45.20) when the VPN tries to start I get an error in the remote firewall's logs which says that the incoming certificate is broken.  I am beginning to suspect that there is a routing problem, and that some response is coming from the second external interface of the local firewall, but I can't see why.  An additional symptom is that neither of the external interfaces of this firewall can be accessed from the Internet, even from IP addresses that are permitted for management purposes.  I have had Verisign reissue the certificate, I have reinstalled the primary and secondary intermediates, and I have rebooted the firewall.  Can anyone provide any insight into this problem?

[spuluka]

You don't have the configuration of the harbor.testlogic.com site.  But I notice that your gateway on the stockade.testlogic.com site is configured using the ip address and not the FQDN.  I believe that you need to use the FQDN for the gateways on both sides for the certificates to fully match and pass in this case.

[melodien]

Sorry to be dim on this, but how do I do that?  The SSG seems insistent on using IP addresses.

[spuluka]

Do you have DNS servers setup for the firewall to use?

I have all of my gateways configured using DNS names even when using shared secrets.  It just makes ip address changes down the road easier.

You don't mention your screenOS version.  I've only used 6.x so maybe the ip address requirement is in earlier versions.

[melodien]

I worked it out (I  really need more sleep).  This is so obvious I could kick myself.

Many thanks

[melodien]

OK, still not working.  I do have DNS set up.  Both gateways are configured to use FQDN.  The error in the logs says "Cert received has a different FQDN SubAltName than expected".  I am beginning to lose hope.

[spuluka]

By my reading of kb5833  you will need to put the FQDN of each site with the certificates into the local id  and peer id fields on your gateway object.

http://kb.juniper.net/InfoCenter/index?page=content&id=KB5833

[melodien]

After weeks of troubleshooting, getting certificates reissued, and spending hours on the phone with Juniper technical support (who are lovely, by the way), this still does not work.  The problem appears to be that whatever the SSG expects to find in the FQDN field is just not there:  

2011-06-28 17:50:25 : IKE<115.70.123.123> recv cert with IP(0.0.0.0), FQDN(none), RFC822(none)

## 2011-06-28 17:50:25 : IKE<115.70.123.123> Phase 1: Cert received has a different FQDN SubAltName than expected.

## 2011-06-28 17:50:25 : IKE<115.70.123.123> id in cert is not matched to id payload. abort.

## 2011-06-28 17:50:25 : IKE<115.70.221.123.123> pki_msg: pki state<0>ike state<2/80530f>

## 2011-06-28 17:50:29 : IKE<115.70.123.123> ike packet, len 1952, action 0

## 2011-06-28 17:50:29 : IKE<115.70.123.123> Catcher: received 1924 bytes from socket.

However, Verisign say that the certificate is correct, and that since the CN is present (and resolves), that everything is OK from their perspective.  I surely cannot be the only person with two Juniper firewalls and Verisign certificates: has anyone else hit this problem before?

[echidov]

Hi,

To see the IKE exchange in details, including FQDNs etc. you should use:

undebug all

clear db

debug ike detail

debug ike pki

....

undebug all

get db str

The remote peer seems to send an empty string instead of any ID type supported on SSG : recv cert with IP(0.0.0.0), FQDN(none), RFC822(none)

I would also recommend to select a "Preffered certificate" in the IKE gateway configuration.

[melodien]

This has already been done.  Juniper support has logged into the firewall and double checked it: all correct.  Any other thoughts?  I'm beginning to wonder if Verisign has issued me the wrong type of certificates.