Store

Feed

Categories

Ads

Recent Posts

Ads

Security Advisories

RSS FreeBSD Advisories

RSS NetBSD Advisories

How do I determine the expiration date of a p12 certificate?

First you will need to translate the pkcs12 certificate into a PEM certificate.
The PEM certificate is only needed temporarily and can later be removed.

$ openssl pkcs12 -in certificate.p12 -out tempcrt.pem
Enter Import Password:
MAC verified OK
Enter PEM pass phrase: pass
Verifying - Enter PEM pass phrase: pass

 

Now, we use the tempcrt.pem that we generated to determine the expiration date. The first method, which only displays the expiration date can be retrieved like this:

$ openssl x509 -in tempcrt.pem -noout -enddate
notAfter=Jan  3 23:19:24 2009 GMT

 

The second method which includes a lot more detail about the certificate below, I’ve only included the details relevant to the creation and expiration dates.

$ openssl x509 -in tempcrt.pem -noout -text
        [ ... snip ... ]
        Validity
            Not Before: Jan  3 23:19:24 2008 GMT
            Not After : Jan  3 23:19:24 2009 GMT
        [ ... snip ... ]

 

Fixing PCRE_UTF8 Errors in FreeBSD

I have recently encountered this error:
PHP Warning: preg_match(): Compilation failed: this version of PCRE is not compiled with PCRE_UTF8 support at offset 0

And despite some of the suggested solutions I have found in various Drupal and MediaWiki forums, all of them related to older versions of ports.
The version of pcre I have installed is 7.8. as seen here:

PCRE version 7.8 2008-09-05
Compiled with
UTF-8 support
Unicode properties support
Newline sequence is LF
\R matches all Unicode newlines
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack

But the curious thing is phpinfo(), told a different story.

 
Why was phpinfo() telling me the version of pcre was 5.0.13?
I checked various things like which libraries php was linked to, and sure enough it was in fact the libpcre that it should have been. After countless iterations of “let me tweak this Makefile and see if it makes a difference” and countless rebuilds of pcre and php, it occurred me, what about Apache? Now I’m not really sure why I this occurred to me, or why it did not occur to me earlier, perhaps it was a result of having felt I had already exhausted the rest of my options.

So I took a look at the Apache build config:

# cd /usr/ports/www/apache22
# make config


 
Apparently the pcre Apache is using is a bundled one, so I decided to change this to use devel/pcre, where I know UTF-8 support is enabled.

 
and proceeded to rebuild and reinstall the apache22 port.
After restarting apache, my first test was to inspect what phpinfo() was reporting.

 
Now phpinfo is agreeing with what I originally expected it to, the pcre port that is installed. I proceeded to test my php code with great success and have not seen the error since.

I encountered this on FreeBSD 7.0 , Apache 2.2.9, PHP 5.2.7, and pcre 7.8. But given the large number of seemingly unresolved threads I’ve encountered through google I expect that there are similar situations in other operating systems and software versions as well.

Setting up IPSec over GRE on OpenBSD

This document will explain howto set up an IPSec encrypted GRE tunnel on OpenBSD. In the document, both end points are OpenBSD 4.1 systems, however it should be fairly straight forward to implement on other systems.

To start, I would advise disabling pf on gre0 and enc0 until you have the encrypted tunnel working, this will eliminate pf from any toubleshooting you may have to do, you can do that by adding the following in /etc/pf.conf, make sure you re-load the pf rules.

set skip on enc0
set skip on gre0

 
Now, on to the tutorial…
Assume two hosts in disparate parts of the world with the following interfaces

Host A
   public interface 10.0.0.5
   private interface 10.0.50.0/24

Host B
   public interface 192.168.0.5
   private interface 192.168.50.0/24

 
First, enable gre on both hosts A and B by enabling the sysctl net.inet.gre.allow

# sysctl -w net.inet.gre.allow=1

 
To make it more permanent, add net.inet.gre.allow=1 to /etc/sysctl.conf.

Now, we will construct a gre tunnel to allow their private networks to communicate.

On Host A you would run the following

# ifconfig gre0 create
# ifconfig gre0 172.16.0.1 172.16.0.2 netmask 0xffffffff link0 up
# ifconfig gre0 tunnel 10.0.0.5 192.168.0.5
# route add -net 192.168.50 -netmask 255.255.255.0 172.16.0.2

 
Where did 172.16.0.1 and 172.16.0.2 come from, you might ask? These addresses create the point to point gre tunnel, you should pick them from RFC1918 space that is unused in the network(s) you will be connecting.

On to Host B

# ifconfig gre0 create
# ifconfig gre0 172.16.0.2 172.16.0.1 netmask 0xffffffff link0 up
# ifconfig gre0 tunnel 192.168.0.5 10.0.0.5
# route add -net 10.0.50 -netmask 255.255.255.0 172.16.0.1

 
Once you’ve proven a host on 10.0.50.x can communicate with a host on 192.168.50.x, you can write the gre to /etc/hostname.gre0.

Host A’s /etc/hostname.gre0 looks like this,

172.16.0.1 172.16.0.2 netmask 0xffffffff link0 up
tunnel 10.0.0.5 192.168.0.5
!route add -net 192.168.50 -netmask 255.255.255.0 172.16.0.2

 
At this point your GRE tunnel should be working, do not move onto implementing IPSec until your GRE tunnel is functioning, it will only complicate troubleshooting

Now, enable ipsec on both hosts A and B by enabling the sysctl net.inet.esp.enable

# sysctl -w net.inet.esp.enable=1

 
To make it more permanent, add net.inet.esp.enable=1 to /etc/sysctl.conf.

Now, in this document we will be using public key authentication, to implement x509 certificate authentication please refer to this document.

For public key encryption, you will make use of the file /etc/isakmpd/local.pub. If for some reason this file does not exist, check to see if /etc/isakmpd/private/local.key exists, if neither exists you can create them with the following commands.

# /usr/sbin/openssl genrsa -out /etc/isakmpd/private/local.key 1024
# chmod 600 /etc/isakmpd/private/local.key
# openssl rsa -out /etc/isakmpd/local.pub \
                    -in /etc/isakmpd/private/local.key -pubout

 
If /etc/isakmpd/private/local.key exists but /etc/isakmpd/local.pub does not, you can generate it with the command

# openssl rsa -out /etc/isakmpd/local.pub \
                    -in /etc/isakmpd/private/local.key -pubout

 
Now, you’ll want to copy Host A’s /etc/isakmpd/local.pub to Host B and copy it to /etc/isakmpd/pubkeys/ipv4/10.0.0.5

Note: 10.0.0.5 is a file, not a directory

Likewise, you’ll need to copy Host B’s /etc/isakmpd/local.pub to Host A and copy it to /etc/isakmpd/pubkeys/ipv4/192.168.0.5

Once these have been copied, you need to setup ipsec, Host A’s /etc/ipsec.conf should contain the following

ike esp transport from 10.0.0.5 to 192.168.0.5

 
And Host B’s /etc/ipsec.conf should contain

ike esp transport from 192.168.0.5 to 10.0.0.5

 
Note: We chose transport, because ipsec is not tunneling our subnets, the gre tunnel is taking care of that for us, we are simply encrypting between the two endpoints of the tunnel.

Now, we start isakmpd and load the ipsec rules

# isakmpd -K
# ipsecctl -f /etc/ipsec.conf

 
Now, to test if you’ve been successful, try to connect from a host on 10.0.50.x to a host on 192.168.50.x.

Assuming you can still connect, run the following on one of the end points:

# tcpdump -ni enc0
tcpdump: WARNING: enc0: no IPv4 address assigned
tcpdump: listening on enc0, link-type ENC
20:07:03.036687 (authentic,confidential): SPI 0x8d8b5b6b: 192.168.50.120 > 10.0.50.10: icmp: echo request (gre encap)
20:07:03.075990 (authentic,confidential): SPI 0xaf01c27a: 10.0.50.10 > 192.168.50.120: icmp: echo reply (gre encap)

 
Success! As the packet dump is telling us, you’ve a gre encapsulated packet, that is also being encrypted.

Now, to make some of those settings more permanent, add the following to /etc/rc.conf.local

isakmpd_flags="-K"
ipsec=YES

 
Now that you have IPSec over GRE working, I would strongly advise you remove the set skip rules added to your pf.conf and modify your pf rules for more stringent enforcement.