Re: openswan: Request for review
Harald Jenny wrote:
> please find attached [...]
Just out of habit I'll look at the templates first.
(Last minute addition: I almost missed s/X509/X.509/g)
> Template: openswan/runlevel_changes
> Type: note
> _Description: Old runlevel management superseded
> Previous versions of the Openswan package allowed the user to choose between
It's nice to see "allow" with an object, but is "user" the word? I
mean, it's a system configuration feature, not a runtime end-user
thing, isn't it? So I would suggest "gave a choice between".
> three different Start/Stop-Levels. Due to changes in the standard system
> startup procedure, this is no longer necessary and useful. For all new
^^^
I suspect that "and" should probably be an "or" (or even "or even").
It would be odd if it was still necessary without being useful.
> installations as well as old ones running in any of the predefined modes,
> sane default levels set will now be set. If you are upgrading from a previous
XXX
Excess word.
> version and changed your Openswan startup parameters, then please take a
> look at NEWS.Debian for instructions on how to modify your setup accordingly.
> Template: openswan/restart
> Type: boolean
> Default: true
> _Description: Do you wish to restart Openswan?
My "debconf doesn't run on wishes" knee-jerk:
Restart Openswan now?
> Restarting Openswan is a good idea, since if there is a security fix, it
recommended,
> will not be fixed until the daemon restarts. Most people expect the daemon
applied
> to restart, so this is generally a good idea. However, this might take down
> existing connections and then bring them back up (including the connection
> currently used for this update, so it is recommended not to restart if you
> are using any of the tunnel for administration).
"Using any of the tunnel"? Rephrase:
[...] However, this might take down
existing connections and then bring them back up, so if you are using such
an Openswan tunnel to connect for this update, restarting is not recommended.
(Assuming my terminology is right.)
> Template: openswan/install_x509_certificate
> Type: boolean
> Default: false
> _Description: Do you want to use a X509 certificate for this host?
an
Or just Use an X509 certificate for this host?
> This installer can automatically create or import a X509 certificate for
^^^^^^^^^^^^^^ an
Don't let debconf talk about itself. How about a passive?
An X509 certificate for this host can be automatically created or imported.
> this host. It can be used to authenticate IPsec connections to other hosts
> and is the preferred way for building up secure IPsec connections. The other
^^^^^^^
"Way of" or "method for".
> possibility would be to use shared secrets (passwords that are the same on
> both sides of the tunnel) for authenticating an connection, but for a larger
a (that makes a change!)
> number of connections, key based authentication is easier to administer and
> more secure.
> .
> If you do not want to this now you can answer "No" and later use the command
^do ^^
> "dpkg-reconfigure openswan" to come back.
See DevRef 6.5.4.2.2 on "answer Yes"; make that
Alternatively you can reject this option and later use the command
> Template: openswan/how_to_get_x509_certificate
> Type: select
> __Choices: create, import
> Default: create
> _Description: Methods for using a X509 certificate to authenticate this host:
> It is possible to create a new X509 certificate with user-defined settings
> or to import an existing public and private key stored in PEM file(s) for
> authenticating IPsec connections.
> .
> If you choose to create a new X509 certificate you will first be presented
> a number of questions which must be answered before the creation can start.
Make that "be presented with" - or save space and say "be asked".
> Please keep in mind that if you want the public key to get signed by
> an existing certification authority you should not select to create a
> self-signed certificate and all the answers given must match exactly the
> requirements of the CA, otherwise the certificate request may be rejected.
> .
> In case you want to import an existing public and private key you will be
^^^^^^^
That's conditional "in case"? You can make that unambiguous by
bulking it up to "In the case that", but it's simpler just to say
"if" (and probably "If you choose to...").
> prompted for their filenames (may be identical if both parts are stored
Slightly pedantic: insert ^which may be...
> together in one file). Optionally you may also specify a filename where the
> public key(s) of the certification authority are kept, but this file cannot
> be the same as the former ones. Please be also aware that the format for the
also be
> X509 certificates has to be PEM and that the private key must not be encrypted
> or the import procedure will fail.
>
> Template: openswan/existing_x509_certificate_filename
> Type: string
> _Description: Please enter the location of your X509 certificate in PEM format:
> Please enter the location of the file containing your X509 certificate in
> PEM format.
No need for a "please" in the short description; and since you don't
mean "Enter its location in PEM format" I would suggest:
_Description: File name of your PEM format X509 certificate:
>
> Template: openswan/existing_x509_key_filename
> Type: string
> _Description: Please enter the location of your X509 private key in PEM format:
> Please enter the location of the file containing the private RSA key
> matching your X509 certificate in PEM format. This can be the same file
> that contains the X509 certificate.
Likewise
_Description: File name of your PEM format X509 private key:
> Template: openswan/existing_x509_rootca_filename
> Type: string
> _Description: You may now enter the location of your X509 RootCA in PEM format:
_Description: File name of your PEM format X509 RootCA:
> Optionally you can now enter the location of the file containing the X509
> certificate authority root used to sign your certificate in PEM format. If you
> do not have one or do not want to use it please leave the field empty. Please
> note that it's not possible to store the RootCA in the same file as your X509
> certificate or private key.
>
> Template: openswan/rsa_key_length
> Type: string
> Default: 2048
> _Description: Please enter which length the created RSA key should have:
"What length", but better:
_Description: Length of RSA key to be created:
> Please enter the length of the created RSA key. it should not be less than
> 1024 bits because this should be considered unsecure and you will probably
> not need anything more than 4096 bits because it only slows the
> authentication process down and is not needed at the moment.
Wobbly at a couple of points, so I rewrote it:
Please enter the required RSA key-length. Anything under 1024 bits
should be considered insecure; anything more than 4096 bits slows down
the authentication process and is not useful at present.
> Template: openswan/x509_self_signed
> Type: boolean
> Default: true
> _Description: Do you want to create a self-signed X509 certificate?
XX XXX XXXX XX C
> This installer can only create self-signed X509 certificates
Watch out, debconf's gaining self-awareness again.
Only self-signed X509 certificates can be created
> automatically, because otherwise a certificate authority is needed to sign
> the certificate request. If you want to create a self-signed certificate,
choose
> you can use it immediately to connect to other IPsec hosts that support
> X509 certificate for authentication of IPsec connections. However, if you
> want to use the new PKI features of Openswan >= 1.91, you will need to
> have all X509 certificates signed by a single certificate authority to
> create a trust path.
1.91 is so very old.
However,
using Openswan's PKI features requires all certificates to be signed by a
single Certificate Authority to create a trust path.
Capitalise CA throughout. Oh, and standardise somewhat arbitrarily
on "Certificate" rather than "Certification Authority".
> .
> If you do not want to create a self-signed certificate, then this
> installer will only create the RSA private key and the certificate request
> and you will have to sign the certificate request with your certificate
> authority.
If you do not choose to create a self-signed certificate, only the RSA
private key and the certificate request will be created, and you will
have to sign the certificate request with your Certificate Authority.
> Template: openswan/x509_country_code
> Type: string
> Default: AT
> _Description: Please enter the country code for the X509 certificate request:
> Please enter the 2 letter country code for your country. This code will be
> placed in the certificate request.
> .
> You really need to enter a valid country code here, because openssl will
> refuse to generate certificates without one. An empty field is allowed for
> any other field of the X.509 certificate, but not for this one.
> .
> Example: AT
I often suggest making the example "GB" since that's one of the few where
an admin might reasonably get it wrong, but I won't put that change in my
patch. Just make sure it mentions 3166.
_Description: Country code for the X509 certificate request:
Please enter the two-letter code for the country the server resides in
(such as "AT" for Austria).
.
OpenSSL will refuse to generate a certificate unless this is a valid
ISO-3166 country code; an empty field is allowed elsewhere in the X.509
certificate, but not here.
> Template: openswan/x509_state_name
> Type: string
> Default:
> _Description: Please enter the state or province name for the X509 certificate request:
> Please enter the full name of the state or province you live in. This name
> will be placed in the certificate request.
> .
> Example: Upper Austria
_Description: State or province name for the X509 certificate request:
Please enter the full name of the state or province the server resides in
(such as "Upper Austria").
> Template: openswan/x509_locality_name
> Type: string
> Default:
> _Description: Please enter the locality name for the X509 certificate request:
> Please enter the locality (e.g. city) where you live. This name will be
> placed in the certificate request.
> .
> Example: Vienna
_Description: Locality name for the X.509 certificate request:
Please enter the locality the server resides in (often a city, such
as "Vienna").
> Template: openswan/x509_organization_name
> Type: string
> Default:
> _Description: Please enter the organization name for the X509 certificate request:
> Please enter the organization (e.g. company) that the X509 certificate
> should be created for. This name will be placed in the certificate
> request.
> .
> Example: Debian
Last time I think we had "Example Inc", but:
_Description: Organization name for the X.509 certificate request:
Please enter the organization the server belongs to (such as "Debian").
> Template: openswan/x509_organizational_unit
> Type: string
> Default:
> _Description: Please enter the organizational unit for the X509 certificate request:
> Please enter the organizational unit (e.g. section) that the X509
> certificate should be created for. This name will be placed in the
> certificate request.
> .
> Example: security group
And here we had "Department of Exemplification", but:
_Description: Organizational unit for the X.509 certificate request:
Please enter the organizational unit the server belongs to (such as
"security group").
> Template: openswan/x509_common_name
> Type: string
> Default:
> _Description: Please enter the common name for the X509 certificate request:
> Please enter the common name (e.g. the host name of this machine) for
> which the X509 certificate should be created for. This name will be placed
> in the certificate request.
> .
> Example: gateway.debian.org
Now, here I think we _should_ follow the RFCs for example hostnames,
and capitalise CN to give the hint that it's jargon:
_Description: Common Name for the X.509 certificate request:
Please enter the Common Name for this host (such as
"gateway.example.org").
> Template: openswan/x509_email_address
> Type: string
> Default:
> _Description: Please enter the email address for the X509 certificate request:
> Please enter the email address of the person or organization who is
> responsible for the X509 certificate, This address will be placed in the
> certificate request.
_Description: Email address for the X.509 certificate request:
Please enter the email address of the person or organization
responsible for the X.509 certificate.
> Template: openswan/no-oe_include_file
> Type: note
> _Description: Modification of /etc/ipsec.conf
> Due to a change in upstream Openswan, opportunistic encryption is no longer
> enabled by default. The no_oe.conf file that was shipped in earlier versions
> to explicitly disable it can therefore no longer be included by ipsec.conf.
> A respective include paragraph will now be automatically removed to ensure
> that Openswan can start correctly.
Respective is almost never the word you're looking for. I assume it's
saying "any include paragraph for no_oe.conf that is found to exist"?
Any such include paragraph will now be automatically removed to ensure
Now back to the package descriptions:
> Package: openswan
> Architecture: any
(Presumably with the Linux kernel connection that has to change to
the full list minus the kfreebsd-*s.)
[...]
> Description: Internet Key Exchange daemon
> Openswan is an IPsec based VPN solution for the Linux kernel. It can use the
> native IPsec stack as well as the KLIPS kernel module. Both IKEv1 and IKEv2
> protocols are supported.
This boilerplate looks fine.
> .
> The Openswan IKE daemon is named pluto. It was inherited from the FreeS/WAN
> project, but provides improved X.509 certificate support and other features.
> .
> In order to use the KLIPS IPsec code instead of the native one, you will
> need to install openswan-modules-source and build the respective module for
> your kernel.
The native "one"? No, code isn't countable. Tricky. Say "native
version".
Oop, disrespective again. Say "the appropriate module for your
kernel".
Mentioning FreeS/WAN has the neat side benefit of being enough of a
hint at "why the name?"
> Package: openswan-dbg
[...]
>
> Package: openswan-doc
[...]
>
> Package: openswan-modules-source
[...]
> Description: Internet Protocol Security kernel module source
> This package contains the source code for the Openswan IPsec kernel module,
> which is required to support the old-style KLIPS ipsecX network interfaces.
> .
> Please note that kernel versions >= 2.6.23 do not need to be patched anymore
> in order to provide NAT Traversal support for KLIPS.
> .
> With this package, modules for different kernel images can be built manually
> or using tools like module-assistant or kernel-package.
This doesn't make the remaining use case(s) very clear. Maybe:
Description: Internet Key Exchange daemon - kernel module source
Openswan is an IPsec based VPN solution for the Linux kernel. It can use the
native IPsec stack as well as the KLIPS kernel module. Both IKEv1 and IKEv2
protocols are supported.
.
This package contains source code for the Openswan IPsec kernel module,
which can be used with tools like module-assistant or kernel-package
for manual building of local kernel images.
.
Kernel versions >= 2.6.23 no longer need to be patched to provide NAT
Traversal support for KLIPS, but do need patching to support the old-style
KLIPS ipsecX network interfaces.
(I may be getting this wrong, of course.)
> Package: openswan-modules-dkms
[...]
> Description: Internet Protocol Security kernel module source (DKMS)
> This package contains the source code for the Openswan IPsec kernel module,
> which is required to support the old-style KLIPS ipsecX network interfaces.
> .
> Please note that kernel versions >= 2.6.23 do not need to be patched anymore
> in order to provide NAT Traversal support for KLIPS.
> .
> With this package, modules for local kernel images are automatically built
> and installed every time upgrades of relevant kernel packages are installed.
Oh, this is new to me. Does this package really contain duplicate
source, instead of just a dependency on openswan-modules-source?
Description: Internet Key Exchange daemon - DKMS source
Openswan is an IPsec based VPN solution for the Linux kernel. It can use the
native IPsec stack as well as the KLIPS kernel module. Both IKEv1 and IKEv2
protocols are supported.
.
This package contains source code for the Openswan IPsec kernel module,
which can be used with DKMS so that local kernel images are automatically
built and installed every time relevant kernel packages are upgraded.
.
Kernel versions >= 2.6.23 no longer need to be patched to provide NAT
Traversal support for KLIPS, but do need patching to support the old-style
KLIPS ipsecX network interfaces.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff -ru openswan.old/control openswan.jbr/control
--- openswan.old/control 2010-04-12 16:00:13.000000000 +0100
+++ openswan.jbr/control 2010-04-12 16:19:40.000000000 +0100
@@ -25,8 +25,8 @@
The Openswan IKE daemon is named pluto. It was inherited from the FreeS/WAN
project, but provides improved X.509 certificate support and other features.
.
- In order to use the KLIPS IPsec code instead of the native one, you will
- need to install openswan-modules-source and build the respective module for
+ In order to use the KLIPS IPsec code instead of the native version, you will
+ need to install openswan-modules-source and build the appropriate module for
your kernel.
Package: openswan-dbg
@@ -62,27 +62,33 @@
Recommends: module-assistant | kernel-package, linux-headers | linux-source
Suggests: openswan
Homepage: http://www.openswan.org/
-Description: Internet Protocol Security kernel module source
- This package contains the source code for the Openswan IPsec kernel module,
- which is required to support the old-style KLIPS ipsecX network interfaces.
- .
- Please note that kernel versions >= 2.6.23 do not need to be patched anymore
- in order to provide NAT Traversal support for KLIPS.
+Description: Internet Key Exchange daemon - kernel module source
+ Openswan is an IPsec based VPN solution for the Linux kernel. It can use the
+ native IPsec stack as well as the KLIPS kernel module. Both IKEv1 and IKEv2
+ protocols are supported.
.
- With this package, modules for different kernel images can be built manually
- or using tools like module-assistant or kernel-package.
+ This package contains source code for the Openswan IPsec kernel module,
+ which can be used with tools like module-assistant or kernel-package
+ for manual building of local kernel images.
+ .
+ Kernel versions >= 2.6.23 no longer need to be patched to provide NAT
+ Traversal support for KLIPS, but do need patching to support the old-style
+ KLIPS ipsecX network interfaces.
Package: openswan-modules-dkms
Architecture: all
Section: kernel
Depends: ${misc:Depends}, dkms, openswan
Homepage: http://www.openswan.org/
-Description: Internet Protocol Security kernel module source (DKMS)
- This package contains the source code for the Openswan IPsec kernel module,
- which is required to support the old-style KLIPS ipsecX network interfaces.
- .
- Please note that kernel versions >= 2.6.23 do not need to be patched anymore
- in order to provide NAT Traversal support for KLIPS.
+Description: Internet Key Exchange daemon - DKMS source
+ Openswan is an IPsec based VPN solution for the Linux kernel. It can use the
+ native IPsec stack as well as the KLIPS kernel module. Both IKEv1 and IKEv2
+ protocols are supported.
.
- With this package, modules for local kernel images are automatically built
- and installed every time upgrades of relevant kernel packages are installed.
+ This package contains source code for the Openswan IPsec kernel module,
+ which can be used with DKMS so that local kernel images are automatically
+ built and installed every time relevant kernel packages are upgraded.
+ .
+ Kernel versions >= 2.6.23 no longer need to be patched to provide NAT
+ Traversal support for KLIPS, but do need patching to support the old-style
+ KLIPS ipsecX network interfaces.
diff -ru openswan.old/openswan.templates openswan.jbr/openswan.templates
--- openswan.old/openswan.templates 2010-04-12 16:00:14.000000000 +0100
+++ openswan.jbr/openswan.templates 2010-04-12 16:24:59.000000000 +0100
@@ -1,181 +1,161 @@
Template: openswan/runlevel_changes
Type: note
_Description: Old runlevel management superseded
- Previous versions of the Openswan package allowed the user to choose between
+ Previous versions of the Openswan package gave a choice betweenn
three different Start/Stop-Levels. Due to changes in the standard system
- startup procedure, this is no longer necessary and useful. For all new
+ startup procedure, this is no longer necessary or useful. For all new
installations as well as old ones running in any of the predefined modes,
- sane default levels set will now be set. If you are upgrading from a previous
+ sane default levels will now be set. If you are upgrading from a previous
version and changed your Openswan startup parameters, then please take a
look at NEWS.Debian for instructions on how to modify your setup accordingly.
Template: openswan/restart
Type: boolean
Default: true
-_Description: Do you wish to restart Openswan?
- Restarting Openswan is a good idea, since if there is a security fix, it
- will not be fixed until the daemon restarts. Most people expect the daemon
+_Description: Restart Openswan now?
+ Restarting Openswan is recommended, since if there is a security fix, it
+ will not be applied until the daemon restarts. Most people expect the daemon
to restart, so this is generally a good idea. However, this might take down
- existing connections and then bring them back up (including the connection
- currently used for this update, so it is recommended not to restart if you
- are using any of the tunnel for administration).
+ existing connections and then bring them back up, so if you are using such
+ an Openswan tunnel to connect for this update, restarting is not recommended.
Template: openswan/install_x509_certificate
Type: boolean
Default: false
-_Description: Do you want to use a X509 certificate for this host?
- This installer can automatically create or import a X509 certificate for
- this host. It can be used to authenticate IPsec connections to other hosts
- and is the preferred way for building up secure IPsec connections. The other
+_Description: Use an X.509 certificate for this host?
+ An X.509 certificate for this host can be automatically created or imported.
+ It can be used to authenticate IPsec connections to other hosts
+ and is the preferred way of building up secure IPsec connections. The other
possibility would be to use shared secrets (passwords that are the same on
- both sides of the tunnel) for authenticating an connection, but for a larger
+ both sides of the tunnel) for authenticating a connection, but for a larger
number of connections, key based authentication is easier to administer and
more secure.
.
- If you do not want to this now you can answer "No" and later use the command
+ Alternatively you can reject this option and later use the command
"dpkg-reconfigure openswan" to come back.
Template: openswan/how_to_get_x509_certificate
Type: select
__Choices: create, import
Default: create
-_Description: Methods for using a X509 certificate to authenticate this host:
- It is possible to create a new X509 certificate with user-defined settings
+_Description: Methods for using a X.509 certificate to authenticate this host:
+ It is possible to create a new X.509 certificate with user-defined settings
or to import an existing public and private key stored in PEM file(s) for
authenticating IPsec connections.
.
- If you choose to create a new X509 certificate you will first be presented
+ If you choose to create a new X.509 certificate you will first be asked
a number of questions which must be answered before the creation can start.
Please keep in mind that if you want the public key to get signed by
- an existing certification authority you should not select to create a
+ an existing Certificate Authority you should not select to create a
self-signed certificate and all the answers given must match exactly the
requirements of the CA, otherwise the certificate request may be rejected.
.
- In case you want to import an existing public and private key you will be
- prompted for their filenames (may be identical if both parts are stored
+ If you want to import an existing public and private key you will be
+ prompted for their filenames (which may be identical if both parts are stored
together in one file). Optionally you may also specify a filename where the
- public key(s) of the certification authority are kept, but this file cannot
- be the same as the former ones. Please be also aware that the format for the
- X509 certificates has to be PEM and that the private key must not be encrypted
+ public key(s) of the Certificate Authority are kept, but this file cannot
+ be the same as the former ones. Please also be aware that the format for the
+ X.509 certificates has to be PEM and that the private key must not be encrypted
or the import procedure will fail.
Template: openswan/existing_x509_certificate_filename
Type: string
-_Description: Please enter the location of your X509 certificate in PEM format:
- Please enter the location of the file containing your X509 certificate in
+_Description: File name of your PEM format X.509 certificate:
+ Please enter the location of the file containing your X.509 certificate in
PEM format.
Template: openswan/existing_x509_key_filename
Type: string
-_Description: Please enter the location of your X509 private key in PEM format:
+_Description: File name of your PEM format X.509 private key:
Please enter the location of the file containing the private RSA key
- matching your X509 certificate in PEM format. This can be the same file
- that contains the X509 certificate.
+ matching your X.509 certificate in PEM format. This can be the same file
+ that contains the X.509 certificate.
Template: openswan/existing_x509_rootca_filename
Type: string
-_Description: You may now enter the location of your X509 RootCA in PEM format:
- Optionally you can now enter the location of the file containing the X509
- certificate authority root used to sign your certificate in PEM format. If you
+_Description: File name of your PEM format X.509 RootCA:
+ Optionally you can now enter the location of the file containing the X.509
+ Certificate Authority root used to sign your certificate in PEM format. If you
do not have one or do not want to use it please leave the field empty. Please
- note that it's not possible to store the RootCA in the same file as your X509
+ note that it's not possible to store the RootCA in the same file as your X.509
certificate or private key.
Template: openswan/rsa_key_length
Type: string
Default: 2048
-_Description: Please enter which length the created RSA key should have:
- Please enter the length of the created RSA key. it should not be less than
- 1024 bits because this should be considered unsecure and you will probably
- not need anything more than 4096 bits because it only slows the
- authentication process down and is not needed at the moment.
+_Description: Length of RSA key to be created:
+ Please enter the required RSA key-length. Anything under 1024 bits
+ should be considered insecure; anything more than 4096 bits slows down
+ the authentication process and is not useful at present.
Template: openswan/x509_self_signed
Type: boolean
Default: true
-_Description: Do you want to create a self-signed X509 certificate?
- This installer can only create self-signed X509 certificates
- automatically, because otherwise a certificate authority is needed to sign
+_Description: Create a self-signed X.509 certificate?
+ Only self-signed X.509 certificates can be created
+ automatically, because otherwise a Certificate Authority is needed to sign
the certificate request. If you want to create a self-signed certificate,
you can use it immediately to connect to other IPsec hosts that support
- X509 certificate for authentication of IPsec connections. However, if you
+ X.509 certificate for authentication of IPsec connections. However, if you
want to use the new PKI features of Openswan >= 1.91, you will need to
- have all X509 certificates signed by a single certificate authority to
+ have all X.509 certificates signed by a single certificate authority to
create a trust path.
.
- If you do not want to create a self-signed certificate, then this
- installer will only create the RSA private key and the certificate request
- and you will have to sign the certificate request with your certificate
- authority.
+ If you do not choose to create a self-signed certificate, only the RSA
+ private key and the certificate request will be created, and you will
+ have to sign the certificate request with your Certificate Authority.
Template: openswan/x509_country_code
Type: string
Default: AT
-_Description: Please enter the country code for the X509 certificate request:
- Please enter the 2 letter country code for your country. This code will be
- placed in the certificate request.
- .
- You really need to enter a valid country code here, because openssl will
- refuse to generate certificates without one. An empty field is allowed for
- any other field of the X.509 certificate, but not for this one.
- .
- Example: AT
+_Description: Country code for the X.509 certificate request:
+ Please enter the two-letter code for the country the server resides in
+ (such as "AT" for Austria).
+ .
+ OpenSSL will refuse to generate a certificate unless this is a valid
+ ISO-3166 country code; an empty field is allowed elsewhere in the X.509
+ certificate, but not here.
Template: openswan/x509_state_name
Type: string
Default:
-_Description: Please enter the state or province name for the X509 certificate request:
- Please enter the full name of the state or province you live in. This name
- will be placed in the certificate request.
- .
- Example: Upper Austria
+ _Description: State or province name for the X.509 certificate request:
+ Please enter the full name of the state or province the server resides in
+ (such as "Upper Austria").
Template: openswan/x509_locality_name
Type: string
Default:
-_Description: Please enter the locality name for the X509 certificate request:
- Please enter the locality (e.g. city) where you live. This name will be
- placed in the certificate request.
- .
- Example: Vienna
+_Description: Locality name for the X.509 certificate request:
+ Please enter the locality the server resides in (often a city, such
+ as "Vienna").
Template: openswan/x509_organization_name
Type: string
Default:
-_Description: Please enter the organization name for the X509 certificate request:
- Please enter the organization (e.g. company) that the X509 certificate
- should be created for. This name will be placed in the certificate
- request.
- .
- Example: Debian
+_Description: Organization name for the X.509 certificate request:
+ Please enter the organization the server belongs to (such as "Debian").
Template: openswan/x509_organizational_unit
Type: string
Default:
-_Description: Please enter the organizational unit for the X509 certificate request:
- Please enter the organizational unit (e.g. section) that the X509
- certificate should be created for. This name will be placed in the
- certificate request.
- .
- Example: security group
+_Description: Organizational unit for the X.509 certificate request:
+ Please enter the organizational unit the server belongs to (such as
+ "security group").
Template: openswan/x509_common_name
Type: string
Default:
-_Description: Please enter the common name for the X509 certificate request:
- Please enter the common name (e.g. the host name of this machine) for
- which the X509 certificate should be created for. This name will be placed
- in the certificate request.
- .
- Example: gateway.debian.org
+_Description: Common Name for the X.509 certificate request:
+ Please enter the Common Name for this host (such as
+ "gateway.example.org").
Template: openswan/x509_email_address
Type: string
Default:
-_Description: Please enter the email address for the X509 certificate request:
- Please enter the email address of the person or organization who is
- responsible for the X509 certificate, This address will be placed in the
- certificate request.
+_Description: Email address for the X.509 certificate request:
+ Please enter the email address of the person or organization
+ responsible for the X.509 certificate.
Template: openswan/no-oe_include_file
Type: note
@@ -183,5 +163,5 @@
Due to a change in upstream Openswan, opportunistic encryption is no longer
enabled by default. The no_oe.conf file that was shipped in earlier versions
to explicitly disable it can therefore no longer be included by ipsec.conf.
- A respective include paragraph will now be automatically removed to ensure
+ Any such include paragraph will now be automatically removed to ensure
that Openswan can start correctly.
Template: openswan/runlevel_changes
Type: note
_Description: Old runlevel management superseded
Previous versions of the Openswan package gave a choice betweenn
three different Start/Stop-Levels. Due to changes in the standard system
startup procedure, this is no longer necessary or useful. For all new
installations as well as old ones running in any of the predefined modes,
sane default levels will now be set. If you are upgrading from a previous
version and changed your Openswan startup parameters, then please take a
look at NEWS.Debian for instructions on how to modify your setup accordingly.
Template: openswan/restart
Type: boolean
Default: true
_Description: Restart Openswan now?
Restarting Openswan is recommended, since if there is a security fix, it
will not be applied until the daemon restarts. Most people expect the daemon
to restart, so this is generally a good idea. However, this might take down
existing connections and then bring them back up, so if you are using such
an Openswan tunnel to connect for this update, restarting is not recommended.
Template: openswan/install_x509_certificate
Type: boolean
Default: false
_Description: Use an X.509 certificate for this host?
An X.509 certificate for this host can be automatically created or imported.
It can be used to authenticate IPsec connections to other hosts
and is the preferred way of building up secure IPsec connections. The other
possibility would be to use shared secrets (passwords that are the same on
both sides of the tunnel) for authenticating a connection, but for a larger
number of connections, key based authentication is easier to administer and
more secure.
.
Alternatively you can reject this option and later use the command
"dpkg-reconfigure openswan" to come back.
Template: openswan/how_to_get_x509_certificate
Type: select
__Choices: create, import
Default: create
_Description: Methods for using a X.509 certificate to authenticate this host:
It is possible to create a new X.509 certificate with user-defined settings
or to import an existing public and private key stored in PEM file(s) for
authenticating IPsec connections.
.
If you choose to create a new X.509 certificate you will first be asked
a number of questions which must be answered before the creation can start.
Please keep in mind that if you want the public key to get signed by
an existing Certificate Authority you should not select to create a
self-signed certificate and all the answers given must match exactly the
requirements of the CA, otherwise the certificate request may be rejected.
.
If you want to import an existing public and private key you will be
prompted for their filenames (which may be identical if both parts are stored
together in one file). Optionally you may also specify a filename where the
public key(s) of the Certificate Authority are kept, but this file cannot
be the same as the former ones. Please also be aware that the format for the
X.509 certificates has to be PEM and that the private key must not be encrypted
or the import procedure will fail.
Template: openswan/existing_x509_certificate_filename
Type: string
_Description: File name of your PEM format X.509 certificate:
Please enter the location of the file containing your X.509 certificate in
PEM format.
Template: openswan/existing_x509_key_filename
Type: string
_Description: File name of your PEM format X.509 private key:
Please enter the location of the file containing the private RSA key
matching your X.509 certificate in PEM format. This can be the same file
that contains the X.509 certificate.
Template: openswan/existing_x509_rootca_filename
Type: string
_Description: File name of your PEM format X.509 RootCA:
Optionally you can now enter the location of the file containing the X.509
Certificate Authority root used to sign your certificate in PEM format. If you
do not have one or do not want to use it please leave the field empty. Please
note that it's not possible to store the RootCA in the same file as your X.509
certificate or private key.
Template: openswan/rsa_key_length
Type: string
Default: 2048
_Description: Length of RSA key to be created:
Please enter the required RSA key-length. Anything under 1024 bits
should be considered insecure; anything more than 4096 bits slows down
the authentication process and is not useful at present.
Template: openswan/x509_self_signed
Type: boolean
Default: true
_Description: Create a self-signed X.509 certificate?
Only self-signed X.509 certificates can be created
automatically, because otherwise a Certificate Authority is needed to sign
the certificate request. If you want to create a self-signed certificate,
you can use it immediately to connect to other IPsec hosts that support
X.509 certificate for authentication of IPsec connections. However, if you
want to use the new PKI features of Openswan >= 1.91, you will need to
have all X.509 certificates signed by a single certificate authority to
create a trust path.
.
If you do not choose to create a self-signed certificate, only the RSA
private key and the certificate request will be created, and you will
have to sign the certificate request with your Certificate Authority.
Template: openswan/x509_country_code
Type: string
Default: AT
_Description: Country code for the X.509 certificate request:
Please enter the two-letter code for the country the server resides in
(such as "AT" for Austria).
.
OpenSSL will refuse to generate a certificate unless this is a valid
ISO-3166 country code; an empty field is allowed elsewhere in the X.509
certificate, but not here.
Template: openswan/x509_state_name
Type: string
Default:
_Description: State or province name for the X.509 certificate request:
Please enter the full name of the state or province the server resides in
(such as "Upper Austria").
Template: openswan/x509_locality_name
Type: string
Default:
_Description: Locality name for the X.509 certificate request:
Please enter the locality the server resides in (often a city, such
as "Vienna").
Template: openswan/x509_organization_name
Type: string
Default:
_Description: Organization name for the X.509 certificate request:
Please enter the organization the server belongs to (such as "Debian").
Template: openswan/x509_organizational_unit
Type: string
Default:
_Description: Organizational unit for the X.509 certificate request:
Please enter the organizational unit the server belongs to (such as
"security group").
Template: openswan/x509_common_name
Type: string
Default:
_Description: Common Name for the X.509 certificate request:
Please enter the Common Name for this host (such as
"gateway.example.org").
Template: openswan/x509_email_address
Type: string
Default:
_Description: Email address for the X.509 certificate request:
Please enter the email address of the person or organization
responsible for the X.509 certificate.
Template: openswan/no-oe_include_file
Type: note
_Description: Modification of /etc/ipsec.conf
Due to a change in upstream Openswan, opportunistic encryption is no longer
enabled by default. The no_oe.conf file that was shipped in earlier versions
to explicitly disable it can therefore no longer be included by ipsec.conf.
Any such include paragraph will now be automatically removed to ensure
that Openswan can start correctly.
Source: openswan
Section: net
Priority: optional
Maintainer: Rene Mayrhofer <rmayr@debian.org>
Uploaders: Harald Jenny <harald@a-little-linux-box.at>
Standards-Version: 3.8.4
Vcs-Browser: http://svn.debian.org/viewsvn/pkg-openswan
Vcs-Svn: svn://svn.debian.org/svn/pkg-openswan
Build-Depends: debhelper (>= 7.1), libgmp3-dev, libssl-dev (>= 0.9.8), htmldoc, man2html, libcurl4-openssl-dev, libopensc2-dev, libldap2-dev, libpam0g-dev, libkrb5-dev, bison, flex, dpatch, bzip2, po-debconf
Homepage: http://www.openswan.org/
Package: openswan
Architecture: any
Pre-Depends: debconf | debconf-2.0
Depends: ${shlibs:Depends}, ${misc:Depends}, bsdmainutils, openssl, host, iproute, iproute (>=20041019-0.1) | ipsec-tools
Suggests: openswan-modules-source, curl
Provides: ike-server
Conflicts: freeswan (<< 2.04-12)
Homepage: http://www.openswan.org/
Description: Internet Key Exchange daemon
Openswan is an IPsec based VPN solution for the Linux kernel. It can use the
native IPsec stack as well as the KLIPS kernel module. Both IKEv1 and IKEv2
protocols are supported.
.
The Openswan IKE daemon is named pluto. It was inherited from the FreeS/WAN
project, but provides improved X.509 certificate support and other features.
.
In order to use the KLIPS IPsec code instead of the native version, you will
need to install openswan-modules-source and build the appropriate module for
your kernel.
Package: openswan-dbg
Architecture: any
Section: debug
Priority: extra
Depends: ${misc:Depends}, openswan
Homepage: http://www.openswan.org/
Description: Internet Key Exchange daemon - debugging symbols
Openswan is an IPsec based VPN solution for the Linux kernel. It can use the
native IPsec stack as well as the KLIPS kernel module. Both IKEv1 and IKEv2
protocols are supported.
.
This package provides the symbols needed for debugging of openswan
binaries.
Package: openswan-doc
Architecture: all
Section: doc
Suggests: openswan
Homepage: http://www.openswan.org/
Description: Internet Key Exchange daemon - documentation
Openswan is an IPsec based VPN solution for the Linux kernel. It can use the
native IPsec stack as well as the KLIPS kernel module. Both IKEv1 and IKEv2
protocols are supported.
.
This package provides the free parts of the documentation for Openswan.
Package: openswan-modules-source
Architecture: all
Section: kernel
Depends: ${misc:Depends}, debhelper, bzip2
Recommends: module-assistant | kernel-package, linux-headers | linux-source
Suggests: openswan
Homepage: http://www.openswan.org/
Description: Internet Key Exchange daemon - kernel module source
Openswan is an IPsec based VPN solution for the Linux kernel. It can use the
native IPsec stack as well as the KLIPS kernel module. Both IKEv1 and IKEv2
protocols are supported.
.
This package contains source code for the Openswan IPsec kernel module,
which can be used with tools like module-assistant or kernel-package
for manual building of local kernel images.
.
Kernel versions >= 2.6.23 no longer need to be patched to provide NAT
Traversal support for KLIPS, but do need patching to support the old-style
KLIPS ipsecX network interfaces.
Package: openswan-modules-dkms
Architecture: all
Section: kernel
Depends: ${misc:Depends}, dkms, openswan
Homepage: http://www.openswan.org/
Description: Internet Key Exchange daemon - DKMS source
Openswan is an IPsec based VPN solution for the Linux kernel. It can use the
native IPsec stack as well as the KLIPS kernel module. Both IKEv1 and IKEv2
protocols are supported.
.
This package contains source code for the Openswan IPsec kernel module,
which can be used with DKMS so that local kernel images are automatically
built and installed every time relevant kernel packages are upgraded.
.
Kernel versions >= 2.6.23 no longer need to be patched to provide NAT
Traversal support for KLIPS, but do need patching to support the old-style
KLIPS ipsecX network interfaces.
Reply to: