ScreenOS Firewalls (NOT SRX)
Showing results for 
Search instead for 
Do you mean 
Reply
Contributor
Posts: 14
Registered: ‎03-20-2011
0 Kudos

VPN works with keys, not with certificates

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?

 

 

Distinguished Expert
Posts: 3,892
Registered: ‎03-30-2009
0 Kudos

Re: VPN works with keys, not with certificates

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.

Steve Puluka BSEET
Juniper Ambassador
Senior IP Engineer - DQE Communications Pittsburgh, PA
JNCIA-ER JNCIA-EX JNCIS-SEC JNCIP-SEC JNCSP-SEC
JNCIS-FWV JNCIS-SSL JNCDA
JNCIS-SP
ACE PanOS 6
MCP - Managing Server 2003 MCP - Windows XP Professional
MCTS Windows 7
http://puluka.com/home
Contributor
Posts: 14
Registered: ‎03-20-2011
0 Kudos

Re: VPN works with keys, not with certificates

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

Distinguished Expert
Posts: 3,892
Registered: ‎03-30-2009
0 Kudos

Re: VPN works with keys, not with certificates

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.

 

 

Steve Puluka BSEET
Juniper Ambassador
Senior IP Engineer - DQE Communications Pittsburgh, PA
JNCIA-ER JNCIA-EX JNCIS-SEC JNCIP-SEC JNCSP-SEC
JNCIS-FWV JNCIS-SSL JNCDA
JNCIS-SP
ACE PanOS 6
MCP - Managing Server 2003 MCP - Windows XP Professional
MCTS Windows 7
http://puluka.com/home
Contributor
Posts: 14
Registered: ‎03-20-2011
0 Kudos

Re: VPN works with keys, not with certificates

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

Many thanks

Contributor
Posts: 14
Registered: ‎03-20-2011
0 Kudos

Re: VPN works with keys, not with certificates

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.

Distinguished Expert
Posts: 3,892
Registered: ‎03-30-2009
0 Kudos

Re: VPN works with keys, not with certificates

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

Steve Puluka BSEET
Juniper Ambassador
Senior IP Engineer - DQE Communications Pittsburgh, PA
JNCIA-ER JNCIA-EX JNCIS-SEC JNCIP-SEC JNCSP-SEC
JNCIS-FWV JNCIS-SSL JNCDA
JNCIS-SP
ACE PanOS 6
MCP - Managing Server 2003 MCP - Windows XP Professional
MCTS Windows 7
http://puluka.com/home
Highlighted
Contributor
Posts: 14
Registered: ‎03-20-2011
0 Kudos

Re: VPN works with keys, not with certificates

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?

Distinguished Expert
Posts: 858
Registered: ‎11-02-2009
0 Kudos

Re: VPN works with keys, not with certificates

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.

Kind regards,
Edouard
Contributor
Posts: 14
Registered: ‎03-20-2011
0 Kudos

Re: VPN works with keys, not with certificates

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.

Contributor
Posts: 14
Registered: ‎03-20-2011
0 Kudos

RESOLVED: Re: VPN works with keys, not with certificates

[ Edited ]

Finally, it works.  There were actually two problems, which I will document here for future reference.

 

Problem 1: FQDN not appearing in certificate

 

Symptom: You see a line like this in the debug output:

 

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

 

Cause: Verisign certificate issued without a Subject Alternative Name (SAN).

 

Explanation: (I'm not sure if this is unique to Verisign).  Create a CSR on the firewall in the normal manner, entering the FQDN in the Name field and in the FQDN field of the CSR.  When you enroll for an SSL certificate on the Verisign website using this CSR, it will put the FQDN into the Common Name field.  If you then try to put the same FQDN into the SAN field, you will get an error message, and be unable to proceed. Note that Verisign appears to ignore the FQDN field in the CSR anyway, just looking at the Name field.

 

After some time spent talking to Verisign, they sent me this note

<Start>

  

What you can do in future if you want the common name added as a SAN is add a alternate SAN 

Example: You order your certificate with www.domain.com 

You add domain.com as a SAN.

Our system will automatically add www.domain.com as a 2nd SAN to your cert giving you

Common name: www.domain.com
SANs: domain.com & www.domain.com

<End>

 

This worked for me, in that the FQDN was in the certificate properly, and debug showed that that part of VPN setup was working correctly.  However, the VPN still did not come up correctly.

 

Problem: VPN not coming up.

 

Symptoms:  One side showed Phase 1 as completing correctly, the other side did not.  The failing side had this error in the debug:

## 2011-07-07 17:00:53 : IKE<203.145.34.12> re-trans timer expired, msg retry (4) (80531f/2)

 

Cause: certificate so large that it was getting fragmented, and then the screen options on the firewall itself were dropping the packets.  The certificate key pair length was 2048: a shorter key might not have produced this problem.

 

Solution: turn off screen options on the untrust side of the firewall.

 

The VPN then came up correctly.

 

I am indebted to the JTAC engineer who worked with me to resolve this case.  His professionalism and persistence were exemplary.