Allow install from https server w/ self signed cert

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Allow install from https server w/ self signed cert

RD Thrush-5
Rather than add load to the OpenBSD snapshot servers, for years I download a snapshot to a local netgear nas server.  With the recent https changes, I'm no longer able to install from that server.  I've appended a console log of a failed install attempt.

Per src/distrib/miniroot/install.sub v1.940, I added the recommended question to the response file, ie.
Unable to connect using https. Use http instead = yes

However, the "ftp: SSL write error: certificate verification failed: self signed certificate" message causes the install to abort.

Here's the patch I used to account for the self signed certificate:
Index: install.sub
===================================================================
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.942
diff -u -p -u -p -r1.942 install.sub
--- install.sub 4 Jan 2017 13:47:29 -0000 1.942
+++ install.sub 5 Jan 2017 11:12:32 -0000
@@ -1578,7 +1578,7 @@ install_http() {
 
  # Consider the https connect failed either if it was refused by
  # the server, or it took longer than -w sec (exit code 2).
- if ( (($_rc == 1)) && [[ $_err == *'Connection refused'* ]] ) ||
+ if ( (($_rc == 1)) && [[ $_err == *'Connection refused'* ]] || [[ $_err == *'self signed'* ]] ) ||
  (($_rc == 2)); then
  ask_yn "Unable to connect using https. Use http instead?" ||
  return


######## serial console #########
>> OpenBSD/amd64 BOOT 3.33
Disk    BIOS#   Type    Cyls    Heads   Secs    Flags   Checksum
hd0     0x80    label   1023    255     63      0x2     0xdce59776
hd1     0x81    label   1023    255     63      0x2     0x2db005d6
Region 0: type 1 at 0x0 for 639KB
Region 1: type 2 at 0x9fc00 for 1KB
Region 2: type 2 at 0xf0000 for 64KB
Region 3: type 1 at 0x100000 for 2096000KB
Region 4: type 2 at 0x7ffe0000 for 128KB
Region 5: type 2 at 0xfeffc000 for 16KB
Region 6: type 2 at 0xfffc0000 for 256KB
Low ram: 639KB  High ram: 2096000KB
Total free memory: 2096639KB
boot>
booting hd0a:bsd.rd.new: 3396680+1430528+3876632+0+606208 [72+431976+281240]=0x9914c8
entry point at 0x1001000 [7205c766, 34000004, 24448b12, 3550a304]
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.0-current (RAMDISK_CD) #103: Wed Jan  4 21:48:20 MST 2017
    [hidden email]:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
real mem = 2130575360 (2031MB)
avail mem = 2062315520 (1966MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf0cd0 (9 entries)
bios0: vendor SeaBIOS version "rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org" date 04/01/2014
bios0: QEMU Standard PC (i440FX + PIIX, 1996)
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP SSDT APIC HPET
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Common KVM processor, 3400.46 MHz
cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: apic clock running at 1000MHz
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 0 pa 0xfec00000, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu at acpi0 not configured
"ACPI0006" at acpi0 not configured
"PNP0303" at acpi0 not configured
"PNP0F13" at acpi0 not configured
"PNP0700" at acpi0 not configured
"PNP0501" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
pvbus0 at mainbus0: KVM
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
"Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: <QEMU, QEMU DVD-ROM, 2.2.> ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11
"Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured
vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
vga1: aperture needed
wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Memory" rev 0x00
virtio0: no matching child driver; not configured
virtio1 at pci0 dev 10 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk0 at virtio1
scsibus1 at vioblk0: 2 targets
sd0 at scsibus1 targ 0 lun 0: <VirtIO, Block Device, > SCSI3 0/direct fixed
sd0: 32768MB, 512 bytes/sector, 67108864 sectors
virtio1: msix shared
virtio2 at pci0 dev 11 function 0 "Qumranet Virtio Storage" rev 0x00
vioblk1 at virtio2
scsibus2 at vioblk1: 2 targets
sd1 at scsibus2 targ 0 lun 0: <VirtIO, Block Device, > SCSI3 0/direct fixed
sd1: 51200MB, 512 bytes/sector, 104857600 sectors
virtio2: msix shared
virtio3 at pci0 dev 18 function 0 "Qumranet Virtio Network" rev 0x00
vio0 at virtio3: address 8a:2e:d1:64:f7:6b
virtio3: msix shared
usb0 at uhci0: USB revision 1.0
uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at mainbus0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay1
uhidev0 at uhub0 port 1 configuration 1 interface 0 "QEMU QEMU USB Tablet" rev 2.00/0.00 addr 2
uhidev0: iclass 3/0
uhid at uhidev0 not configured
softraid0 at root
scsibus3 at softraid0: 256 targets
root on rd0a swap on rd0b dump on rd0b
erase ^?, werase ^W, kill ^U, intr ^C, status ^T

Welcome to the OpenBSD/amd64 6.0 installation program.
(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? a
DHCPDISCOVER on vio0 - interval 1
DHCPOFFER from 10.1.2.1 (00:08:a2:0a:73:bd)
DHCPREQUEST on vio0 to 255.255.255.255
DHCPACK from 10.1.2.1 (00:08:a2:0a:73:bd)
bound to 10.1.2.7 -- renewal in 302400 seconds.
Fetching http://tarpit/config/openbsd/amd64/8a:2e:d1:64:f7:6b-upgrade.conf?path=snapshots/amd64
Fetching http://tarpit/config/openbsd/amd64/obsd64-upgrade.conf?path=snapshots/amd64
Performing non-interactive upgrade...
Terminal type? [vt220] vt220
Available disks are: sd0 sd1.
Which disk is the root disk? ('?' for details) [sd0] sd0
Checking root filesystem (fsck -fp /dev/sd0a)...OK.
Mounting root filesystem (mount -o ro /dev/sd0a /mnt)...OK.
DHCPREQUEST on vio0 to 255.255.255.255
DHCPACK from 10.1.2.1 (00:08:a2:0a:73:bd)
bound to 10.1.2.7 -- renewal in 302400 seconds.
Force checking of clean non-root filesystems? [no] no
fsck -p 8f3e304cddb66a7a.g...OK.
fsck -p 8f3e304cddb66a7a.f...OK.
fsck -p 8f3e304cddb66a7a.l...OK.
fsck -p c1a908809de1d866.o...OK.
fsck -p 8f3e304cddb66a7a.e...OK.
/dev/sd0a (8f3e304cddb66a7a.a) on /mnt type ffs (rw, local)
/dev/sd0g (8f3e304cddb66a7a.g) on /mnt/home type ffs (rw, local, nodev, nosuid)
/dev/sd0f (8f3e304cddb66a7a.f) on /mnt/usr type ffs (rw, local, nodev)
/dev/sd0l (8f3e304cddb66a7a.l) on /mnt/usr/local type ffs (rw, local, nodev, wxallowed)
/dev/sd1o (c1a908809de1d866.o) on /mnt/usr/obj type ffs (rw, asynchronous, local, nodev, nosuid)
/dev/sd0e (8f3e304cddb66a7a.e) on /mnt/var type ffs (rw, local, nodev, nosuid)

Let's upgrade the sets!
Location of sets? (cd0 disk http or 'done') [http] http
HTTP proxy URL? (e.g. '<a href="http://proxy:8080'">http://proxy:8080', or 'none') [none] none
HTTP Server? (hostname, list#, 'done' or '?') [10.1.2.15] 10.1.2.15
Server directory? [pub/OpenBSD/snapshots/amd64] pub/OpenBSD/snapshots/amd64
ftp: SSL write error: certificate verification failed: self signed certificate
Looked at https://10.1.2.15/pub/OpenBSD/snapshots/amd64 and found no OpenBSD/amd64 6.0 sets.  The set names looked for were:
    bsd               comp60.tgz        xshare60.tgz      site60-obsd64.tgz
    bsd.rd            man60.tgz         xfont60.tgz
    bsd.mp            game60.tgz        xserv60.tgz
    base60.tgz        xbase60.tgz       site60.tgz
failed; check /tmp/ai/ai.log

Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

Alexander Hall
What's the point of installing over https if you don't care about validating the cert?

On January 5, 2017 12:24:11 PM GMT+01:00, RD Thrush <[hidden email]> wrote:

>Rather than add load to the OpenBSD snapshot servers, for years I
>download a snapshot to a local netgear nas server.  With the recent
>https changes, I'm no longer able to install from that server.  I've
>appended a console log of a failed install attempt.
>
>Per src/distrib/miniroot/install.sub v1.940, I added the recommended
>question to the response file, ie.
>Unable to connect using https. Use http instead = yes
>
>However, the "ftp: SSL write error: certificate verification failed:
>self signed certificate" message causes the install to abort.
>
>Here's the patch I used to account for the self signed certificate:
>Index: install.sub
>===================================================================
>RCS file: /cvs/src/distrib/miniroot/install.sub,v
>retrieving revision 1.942
>diff -u -p -u -p -r1.942 install.sub
>--- install.sub 4 Jan 2017 13:47:29 -0000 1.942
>+++ install.sub 5 Jan 2017 11:12:32 -0000
>@@ -1578,7 +1578,7 @@ install_http() {
>
> # Consider the https connect failed either if it was refused by
> # the server, or it took longer than -w sec (exit code 2).
>- if ( (($_rc == 1)) && [[ $_err == *'Connection refused'* ]] ) ||
>+ if ( (($_rc == 1)) && [[ $_err == *'Connection refused'* ]] || [[
>$_err == *'self signed'* ]] ) ||
> (($_rc == 2)); then
> ask_yn "Unable to connect using https. Use http instead?" ||
> return
>
>
>######## serial console #########
>>> OpenBSD/amd64 BOOT 3.33
>Disk    BIOS#   Type    Cyls    Heads   Secs    Flags   Checksum
>hd0     0x80    label   1023    255     63      0x2     0xdce59776
>hd1     0x81    label   1023    255     63      0x2     0x2db005d6
>Region 0: type 1 at 0x0 for 639KB
>Region 1: type 2 at 0x9fc00 for 1KB
>Region 2: type 2 at 0xf0000 for 64KB
>Region 3: type 1 at 0x100000 for 2096000KB
>Region 4: type 2 at 0x7ffe0000 for 128KB
>Region 5: type 2 at 0xfeffc000 for 16KB
>Region 6: type 2 at 0xfffc0000 for 256KB
>Low ram: 639KB  High ram: 2096000KB
>Total free memory: 2096639KB
>boot>
>booting hd0a:bsd.rd.new: 3396680+1430528+3876632+0+606208
>[72+431976+281240]=0x9914c8
>entry point at 0x1001000 [7205c766, 34000004, 24448b12, 3550a304]
>Copyright (c) 1982, 1986, 1989, 1991, 1993
> The Regents of the University of California.  All rights reserved.
>Copyright (c) 1995-2017 OpenBSD. All rights reserved.
>https://www.OpenBSD.org
>
>OpenBSD 6.0-current (RAMDISK_CD) #103: Wed Jan  4 21:48:20 MST 2017
>    [hidden email]:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
>real mem = 2130575360 (2031MB)
>avail mem = 2062315520 (1966MB)
>mainbus0 at root
>bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf0cd0 (9 entries)
>bios0: vendor SeaBIOS version
>"rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org" date
>04/01/2014
>bios0: QEMU Standard PC (i440FX + PIIX, 1996)
>acpi0 at bios0: rev 0
>acpi0: tables DSDT FACP SSDT APIC HPET
>acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
>cpu0 at mainbus0: apid 0 (boot processor)
>cpu0: Common KVM processor, 3400.46 MHz
>cpu0:
>FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF
>cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
>64b/line 16-way L2 cache
>cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
>cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
>cpu0: apic clock running at 1000MHz
>cpu at mainbus0: not configured
>ioapic0 at mainbus0: apid 0 pa 0xfec00000, version 11, 24 pins
>acpiprt0 at acpi0: bus 0 (PCI0)
>acpicpu at acpi0 not configured
>"ACPI0006" at acpi0 not configured
>"PNP0303" at acpi0 not configured
>"PNP0F13" at acpi0 not configured
>"PNP0700" at acpi0 not configured
>"PNP0501" at acpi0 not configured
>"PNP0A06" at acpi0 not configured
>"ACPI0007" at acpi0 not configured
>"ACPI0007" at acpi0 not configured
>pvbus0 at mainbus0: KVM
>pci0 at mainbus0 bus 0
>pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
>"Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured
>pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA,
>channel 0 wired to compatibility, channel 1 wired to compatibility
>pciide0: channel 0 disabled (no drives)
>atapiscsi0 at pciide0 channel 1 drive 0
>scsibus0 at atapiscsi0: 2 targets
>cd0 at scsibus0 targ 0 lun 0: <QEMU, QEMU DVD-ROM, 2.2.> ATAPI 5/cdrom
>removable
>cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
>uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int
>11
>"Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured
>vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
>vga1: aperture needed
>wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
>virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Memory" rev 0x00
>virtio0: no matching child driver; not configured
>virtio1 at pci0 dev 10 function 0 "Qumranet Virtio Storage" rev 0x00
>vioblk0 at virtio1
>scsibus1 at vioblk0: 2 targets
>sd0 at scsibus1 targ 0 lun 0: <VirtIO, Block Device, > SCSI3 0/direct
>fixed
>sd0: 32768MB, 512 bytes/sector, 67108864 sectors
>virtio1: msix shared
>virtio2 at pci0 dev 11 function 0 "Qumranet Virtio Storage" rev 0x00
>vioblk1 at virtio2
>scsibus2 at vioblk1: 2 targets
>sd1 at scsibus2 targ 0 lun 0: <VirtIO, Block Device, > SCSI3 0/direct
>fixed
>sd1: 51200MB, 512 bytes/sector, 104857600 sectors
>virtio2: msix shared
>virtio3 at pci0 dev 18 function 0 "Qumranet Virtio Network" rev 0x00
>vio0 at virtio3: address 8a:2e:d1:64:f7:6b
>virtio3: msix shared
>usb0 at uhci0: USB revision 1.0
>uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev
>1.00/1.00 addr 1
>isa0 at mainbus0
>com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
>com0: console
>pckbc0 at isa0 port 0x60/5 irq 1 irq 12
>pckbd0 at pckbc0 (kbd slot)
>wskbd0 at pckbd0: console keyboard, using wsdisplay1
>uhidev0 at uhub0 port 1 configuration 1 interface 0 "QEMU QEMU USB
>Tablet" rev 2.00/0.00 addr 2
>uhidev0: iclass 3/0
>uhid at uhidev0 not configured
>softraid0 at root
>scsibus3 at softraid0: 256 targets
>root on rd0a swap on rd0b dump on rd0b
>erase ^?, werase ^W, kill ^U, intr ^C, status ^T
>
>Welcome to the OpenBSD/amd64 6.0 installation program.
>(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? a
>DHCPDISCOVER on vio0 - interval 1
>DHCPOFFER from 10.1.2.1 (00:08:a2:0a:73:bd)
>DHCPREQUEST on vio0 to 255.255.255.255
>DHCPACK from 10.1.2.1 (00:08:a2:0a:73:bd)
>bound to 10.1.2.7 -- renewal in 302400 seconds.
>Fetching
>http://tarpit/config/openbsd/amd64/8a:2e:d1:64:f7:6b-upgrade.conf?path=snapshots/amd64
>Fetching
>http://tarpit/config/openbsd/amd64/obsd64-upgrade.conf?path=snapshots/amd64
>Performing non-interactive upgrade...
>Terminal type? [vt220] vt220
>Available disks are: sd0 sd1.
>Which disk is the root disk? ('?' for details) [sd0] sd0
>Checking root filesystem (fsck -fp /dev/sd0a)...OK.
>Mounting root filesystem (mount -o ro /dev/sd0a /mnt)...OK.
>DHCPREQUEST on vio0 to 255.255.255.255
>DHCPACK from 10.1.2.1 (00:08:a2:0a:73:bd)
>bound to 10.1.2.7 -- renewal in 302400 seconds.
>Force checking of clean non-root filesystems? [no] no
>fsck -p 8f3e304cddb66a7a.g...OK.
>fsck -p 8f3e304cddb66a7a.f...OK.
>fsck -p 8f3e304cddb66a7a.l...OK.
>fsck -p c1a908809de1d866.o...OK.
>fsck -p 8f3e304cddb66a7a.e...OK.
>/dev/sd0a (8f3e304cddb66a7a.a) on /mnt type ffs (rw, local)
>/dev/sd0g (8f3e304cddb66a7a.g) on /mnt/home type ffs (rw, local, nodev,
>nosuid)
>/dev/sd0f (8f3e304cddb66a7a.f) on /mnt/usr type ffs (rw, local, nodev)
>/dev/sd0l (8f3e304cddb66a7a.l) on /mnt/usr/local type ffs (rw, local,
>nodev, wxallowed)
>/dev/sd1o (c1a908809de1d866.o) on /mnt/usr/obj type ffs (rw,
>asynchronous, local, nodev, nosuid)
>/dev/sd0e (8f3e304cddb66a7a.e) on /mnt/var type ffs (rw, local, nodev,
>nosuid)
>
>Let's upgrade the sets!
>Location of sets? (cd0 disk http or 'done') [http] http
>HTTP proxy URL? (e.g. '<a href="http://proxy:8080'">http://proxy:8080', or 'none') [none] none
>HTTP Server? (hostname, list#, 'done' or '?') [10.1.2.15] 10.1.2.15
>Server directory? [pub/OpenBSD/snapshots/amd64]
>pub/OpenBSD/snapshots/amd64
>ftp: SSL write error: certificate verification failed: self signed
>certificate
>Looked at https://10.1.2.15/pub/OpenBSD/snapshots/amd64 and found no
>OpenBSD/amd64 6.0 sets.  The set names looked for were:
>bsd               comp60.tgz        xshare60.tgz      site60-obsd64.tgz
>    bsd.rd            man60.tgz         xfont60.tgz
>    bsd.mp            game60.tgz        xserv60.tgz
>    base60.tgz        xbase60.tgz       site60.tgz
>failed; check /tmp/ai/ai.log

Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

Alexander Hall


On January 5, 2017 11:10:06 PM GMT+01:00, Alexander Hall <[hidden email]> wrote:
>What's the point of installing over https if you don't care about
>validating the cert?

Oh, I read too fast. Please disregard.

/Alexander

>
>On January 5, 2017 12:24:11 PM GMT+01:00, RD Thrush
><[hidden email]> wrote:
>>Rather than add load to the OpenBSD snapshot servers, for years I
>>download a snapshot to a local netgear nas server.  With the recent
>>https changes, I'm no longer able to install from that server.  I've
>>appended a console log of a failed install attempt.
>>
>>Per src/distrib/miniroot/install.sub v1.940, I added the recommended
>>question to the response file, ie.
>>Unable to connect using https. Use http instead = yes
>>
>>However, the "ftp: SSL write error: certificate verification failed:
>>self signed certificate" message causes the install to abort.
>>
>>Here's the patch I used to account for the self signed certificate:
>>Index: install.sub
>>===================================================================
>>RCS file: /cvs/src/distrib/miniroot/install.sub,v
>>retrieving revision 1.942
>>diff -u -p -u -p -r1.942 install.sub
>>--- install.sub 4 Jan 2017 13:47:29 -0000 1.942
>>+++ install.sub 5 Jan 2017 11:12:32 -0000
>>@@ -1578,7 +1578,7 @@ install_http() {
>>
>> # Consider the https connect failed either if it was refused by
>> # the server, or it took longer than -w sec (exit code 2).
>>- if ( (($_rc == 1)) && [[ $_err == *'Connection refused'* ]] ) ||
>>+ if ( (($_rc == 1)) && [[ $_err == *'Connection refused'* ]] || [[
>>$_err == *'self signed'* ]] ) ||
>> (($_rc == 2)); then
>> ask_yn "Unable to connect using https. Use http instead?" ||
>> return
>>
>>
>>######## serial console #########
>>>> OpenBSD/amd64 BOOT 3.33
>>Disk    BIOS#   Type    Cyls    Heads   Secs    Flags   Checksum
>>hd0     0x80    label   1023    255     63      0x2     0xdce59776
>>hd1     0x81    label   1023    255     63      0x2     0x2db005d6
>>Region 0: type 1 at 0x0 for 639KB
>>Region 1: type 2 at 0x9fc00 for 1KB
>>Region 2: type 2 at 0xf0000 for 64KB
>>Region 3: type 1 at 0x100000 for 2096000KB
>>Region 4: type 2 at 0x7ffe0000 for 128KB
>>Region 5: type 2 at 0xfeffc000 for 16KB
>>Region 6: type 2 at 0xfffc0000 for 256KB
>>Low ram: 639KB  High ram: 2096000KB
>>Total free memory: 2096639KB
>>boot>
>>booting hd0a:bsd.rd.new: 3396680+1430528+3876632+0+606208
>>[72+431976+281240]=0x9914c8
>>entry point at 0x1001000 [7205c766, 34000004, 24448b12, 3550a304]
>>Copyright (c) 1982, 1986, 1989, 1991, 1993
>> The Regents of the University of California.  All rights reserved.
>>Copyright (c) 1995-2017 OpenBSD. All rights reserved.
>>https://www.OpenBSD.org
>>
>>OpenBSD 6.0-current (RAMDISK_CD) #103: Wed Jan  4 21:48:20 MST 2017
>>    [hidden email]:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
>>real mem = 2130575360 (2031MB)
>>avail mem = 2062315520 (1966MB)
>>mainbus0 at root
>>bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf0cd0 (9 entries)
>>bios0: vendor SeaBIOS version
>>"rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org" date
>>04/01/2014
>>bios0: QEMU Standard PC (i440FX + PIIX, 1996)
>>acpi0 at bios0: rev 0
>>acpi0: tables DSDT FACP SSDT APIC HPET
>>acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
>>cpu0 at mainbus0: apid 0 (boot processor)
>>cpu0: Common KVM processor, 3400.46 MHz
>>cpu0:
>>FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF
>>cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB
>>64b/line 16-way L2 cache
>>cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries
>direct-mapped
>>cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries
>direct-mapped
>>cpu0: apic clock running at 1000MHz
>>cpu at mainbus0: not configured
>>ioapic0 at mainbus0: apid 0 pa 0xfec00000, version 11, 24 pins
>>acpiprt0 at acpi0: bus 0 (PCI0)
>>acpicpu at acpi0 not configured
>>"ACPI0006" at acpi0 not configured
>>"PNP0303" at acpi0 not configured
>>"PNP0F13" at acpi0 not configured
>>"PNP0700" at acpi0 not configured
>>"PNP0501" at acpi0 not configured
>>"PNP0A06" at acpi0 not configured
>>"ACPI0007" at acpi0 not configured
>>"ACPI0007" at acpi0 not configured
>>pvbus0 at mainbus0: KVM
>>pci0 at mainbus0 bus 0
>>pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
>>"Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured
>>pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA,
>>channel 0 wired to compatibility, channel 1 wired to compatibility
>>pciide0: channel 0 disabled (no drives)
>>atapiscsi0 at pciide0 channel 1 drive 0
>>scsibus0 at atapiscsi0: 2 targets
>>cd0 at scsibus0 targ 0 lun 0: <QEMU, QEMU DVD-ROM, 2.2.> ATAPI 5/cdrom
>>removable
>>cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
>>uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0
>int
>>11
>>"Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured
>>vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00
>>vga1: aperture needed
>>wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation)
>>virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Memory" rev 0x00
>>virtio0: no matching child driver; not configured
>>virtio1 at pci0 dev 10 function 0 "Qumranet Virtio Storage" rev 0x00
>>vioblk0 at virtio1
>>scsibus1 at vioblk0: 2 targets
>>sd0 at scsibus1 targ 0 lun 0: <VirtIO, Block Device, > SCSI3 0/direct
>>fixed
>>sd0: 32768MB, 512 bytes/sector, 67108864 sectors
>>virtio1: msix shared
>>virtio2 at pci0 dev 11 function 0 "Qumranet Virtio Storage" rev 0x00
>>vioblk1 at virtio2
>>scsibus2 at vioblk1: 2 targets
>>sd1 at scsibus2 targ 0 lun 0: <VirtIO, Block Device, > SCSI3 0/direct
>>fixed
>>sd1: 51200MB, 512 bytes/sector, 104857600 sectors
>>virtio2: msix shared
>>virtio3 at pci0 dev 18 function 0 "Qumranet Virtio Network" rev 0x00
>>vio0 at virtio3: address 8a:2e:d1:64:f7:6b
>>virtio3: msix shared
>>usb0 at uhci0: USB revision 1.0
>>uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev
>>1.00/1.00 addr 1
>>isa0 at mainbus0
>>com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
>>com0: console
>>pckbc0 at isa0 port 0x60/5 irq 1 irq 12
>>pckbd0 at pckbc0 (kbd slot)
>>wskbd0 at pckbd0: console keyboard, using wsdisplay1
>>uhidev0 at uhub0 port 1 configuration 1 interface 0 "QEMU QEMU USB
>>Tablet" rev 2.00/0.00 addr 2
>>uhidev0: iclass 3/0
>>uhid at uhidev0 not configured
>>softraid0 at root
>>scsibus3 at softraid0: 256 targets
>>root on rd0a swap on rd0b dump on rd0b
>>erase ^?, werase ^W, kill ^U, intr ^C, status ^T
>>
>>Welcome to the OpenBSD/amd64 6.0 installation program.
>>(I)nstall, (U)pgrade, (A)utoinstall or (S)hell? a
>>DHCPDISCOVER on vio0 - interval 1
>>DHCPOFFER from 10.1.2.1 (00:08:a2:0a:73:bd)
>>DHCPREQUEST on vio0 to 255.255.255.255
>>DHCPACK from 10.1.2.1 (00:08:a2:0a:73:bd)
>>bound to 10.1.2.7 -- renewal in 302400 seconds.
>>Fetching
>>http://tarpit/config/openbsd/amd64/8a:2e:d1:64:f7:6b-upgrade.conf?path=snapshots/amd64
>>Fetching
>>http://tarpit/config/openbsd/amd64/obsd64-upgrade.conf?path=snapshots/amd64
>>Performing non-interactive upgrade...
>>Terminal type? [vt220] vt220
>>Available disks are: sd0 sd1.
>>Which disk is the root disk? ('?' for details) [sd0] sd0
>>Checking root filesystem (fsck -fp /dev/sd0a)...OK.
>>Mounting root filesystem (mount -o ro /dev/sd0a /mnt)...OK.
>>DHCPREQUEST on vio0 to 255.255.255.255
>>DHCPACK from 10.1.2.1 (00:08:a2:0a:73:bd)
>>bound to 10.1.2.7 -- renewal in 302400 seconds.
>>Force checking of clean non-root filesystems? [no] no
>>fsck -p 8f3e304cddb66a7a.g...OK.
>>fsck -p 8f3e304cddb66a7a.f...OK.
>>fsck -p 8f3e304cddb66a7a.l...OK.
>>fsck -p c1a908809de1d866.o...OK.
>>fsck -p 8f3e304cddb66a7a.e...OK.
>>/dev/sd0a (8f3e304cddb66a7a.a) on /mnt type ffs (rw, local)
>>/dev/sd0g (8f3e304cddb66a7a.g) on /mnt/home type ffs (rw, local,
>nodev,
>>nosuid)
>>/dev/sd0f (8f3e304cddb66a7a.f) on /mnt/usr type ffs (rw, local, nodev)
>>/dev/sd0l (8f3e304cddb66a7a.l) on /mnt/usr/local type ffs (rw, local,
>>nodev, wxallowed)
>>/dev/sd1o (c1a908809de1d866.o) on /mnt/usr/obj type ffs (rw,
>>asynchronous, local, nodev, nosuid)
>>/dev/sd0e (8f3e304cddb66a7a.e) on /mnt/var type ffs (rw, local, nodev,
>>nosuid)
>>
>>Let's upgrade the sets!
>>Location of sets? (cd0 disk http or 'done') [http] http
>>HTTP proxy URL? (e.g. '<a href="http://proxy:8080'">http://proxy:8080', or 'none') [none] none
>>HTTP Server? (hostname, list#, 'done' or '?') [10.1.2.15] 10.1.2.15
>>Server directory? [pub/OpenBSD/snapshots/amd64]
>>pub/OpenBSD/snapshots/amd64
>>ftp: SSL write error: certificate verification failed: self signed
>>certificate
>>Looked at https://10.1.2.15/pub/OpenBSD/snapshots/amd64 and found no
>>OpenBSD/amd64 6.0 sets.  The set names looked for were:
>>bsd               comp60.tgz        xshare60.tgz    
>site60-obsd64.tgz
>>    bsd.rd            man60.tgz         xfont60.tgz
>>    bsd.mp            game60.tgz        xserv60.tgz
>>    base60.tgz        xbase60.tgz       site60.tgz
>>failed; check /tmp/ai/ai.log

Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

Stuart Henderson
In reply to this post by Alexander Hall
Related to this (and particularly thinking about autoinstalls),
would it make sense to allow explicit protocols in the hostname?

some.host -> https with http fallback
http://some.host/ -> http only
https://some.host/ -> https only, no fallback

Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

Landry Breuil-5
On Fri, Jan 06, 2017 at 11:28:34AM +0000, Stuart Henderson wrote:
> Related to this (and particularly thinking about autoinstalls),
> would it make sense to allow explicit protocols in the hostname?
>
> some.host -> https with http fallback
> http://some.host/ -> http only
> https://some.host/ -> https only, no fallback

Definitely in favor of less implicit/magic behaviour..

Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

viq .
In reply to this post by RD Thrush-5
I have another issue. I'm preparing OpenBSD vagrant boxes using
https://packer.io and use it's built in http server to serve install.conf
file and siteXY.tgz. The whole setup can be seen at
https://github.com/viq/packer-templates/ and specifically
https://github.com/viq/packer-templates/blob/master/openbsd-current/http/install_amd64.conf
The trick is, I have to specify the port that server is listening on, which
causes install to try to connect to that port using https, and drop dead
there and then as that fails.
Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

viq .
On Fri, Jan 6, 2017 at 12:33 PM, viq <[hidden email]> wrote:

> I have another issue. I'm preparing OpenBSD vagrant boxes using
> https://packer.io and use it's built in http server to serve install.conf
> file and siteXY.tgz. The whole setup can be seen at
> https://github.com/viq/packer-templates/ and specifically https://github.
> com/viq/packer-templates/blob/master/openbsd-current/http/
> install_amd64.conf
> The trick is, I have to specify the port that server is listening on,
> which causes install to try to connect to that port using https, and drop
> dead there and then as that fails.
>

And no, there isn't really an option to make it serve https short of
stunnel, and that would still leave an issue of presenting a certificate.

--
viq
Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

RD Thrush-5
In reply to this post by RD Thrush-5
On 01/06/17 06:28, Stuart Henderson wrote:
> Related to this (and particularly thinking about autoinstalls),
> would it make sense to allow explicit protocols in the hostname?
>
> some.host -> https with http fallback
> http://some.host/ -> http only
> https://some.host/ -> https only, no fallback

That would totally work for my install problem.

FWIW, instead of running a patched install.sub, "rm /etc/ssl/cert.pem" makes the install bypass the https attempt.

Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

Bob Beck-2

On Fri, Jan 06, 2017 at 10:48:37AM -0500, RD Thrush wrote:

> On 01/06/17 06:28, Stuart Henderson wrote:
> > Related to this (and particularly thinking about autoinstalls),
> > would it make sense to allow explicit protocols in the hostname?
> >
> > some.host -> https with http fallback
> > http://some.host/ -> http only
> > https://some.host/ -> https only, no fallback
>
> That would totally work for my install problem.
>
> FWIW, instead of running a patched install.sub, "rm /etc/ssl/cert.pem" makes the install bypass the https attempt.
>

Note, if you're upgrading or otherwise have a way to et a cert.pem bundle onto there to *replace*
the default, you could always drop the signer for your private self-signed server into the cert.pem
bundle, at which point it would be accepted as trusted.

of course if you're just installing you have an interesting chicken and egg problem, unless
you put it somewhere on an https site that does have a real certificate, drop out of the
installer and do

ftp -o /tmp/mysigner.pem https://my.secure.site/mysigner.pem
cat /tmp/mysigner.pem >> /etc/ssl/cert.pem

then continue the install, and you're good.

Almost wonder if it's worth an extra question in the installer to ask
for an https address to retrieve a certficiate bundle to be appended to cert.pem
for the install...





Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

RD Thrush-5
In reply to this post by RD Thrush-5
On 01/07/17 16:13, Bob Beck wrote:

>
> On Fri, Jan 06, 2017 at 10:48:37AM -0500, RD Thrush wrote:
>> On 01/06/17 06:28, Stuart Henderson wrote:
>>> Related to this (and particularly thinking about autoinstalls),
>>> would it make sense to allow explicit protocols in the hostname?
>>>
>>> some.host -> https with http fallback
>>> http://some.host/ -> http only
>>> https://some.host/ -> https only, no fallback
>>
>> That would totally work for my install problem.
>>
>> FWIW, instead of running a patched install.sub, "rm /etc/ssl/cert.pem" makes the install bypass the https attempt.
>>
>
> Note, if you're upgrading or otherwise have a way to et a cert.pem bundle onto there to *replace*
> the default, you could always drop the signer for your private self-signed server into the cert.pem
> bundle, at which point it would be accepted as trusted.

In an ideal world, I'd have a valid certificate for this local nas server...


> of course if you're just installing you have an interesting chicken and egg problem, unless
> you put it somewhere on an https site that does have a real certificate, drop out of the
> installer and do
>
> ftp -o /tmp/mysigner.pem https://my.secure.site/mysigner.pem
> cat /tmp/mysigner.pem >> /etc/ssl/cert.pem
>
> then continue the install, and you're good.

Thanks.  Unfortunately, I've been spoiled by the continually improving snapshot install methods and want to preserve typing "a" once for a new -current.


> Almost wonder if it's worth an extra question in the installer to ask
> for an https address to retrieve a certficiate bundle to be appended to cert.pem
> for the install...

That would also solve the self signed cert problem.  Since the install /etc/ssl/cert.pem is transient, your method wouldn't trigger any /etc/daily alarm about a chang in cert.pem.

I hacked a bit on sthen's suggestion but ran into problems testing the https part w/ the OpenBSD servers.  I'm currently unable to do a snapshot autoinstall from ftp[35] via the latest bsd.rd.

FWIW, here's my weak attempt at sthen's suggestion:
Index: install.sub
===================================================================
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.942
diff -u -p -u -p -r1.942 install.sub
--- install.sub 4 Jan 2017 13:47:29 -0000 1.942
+++ install.sub 7 Jan 2017 22:02:52 -0000
@@ -1502,9 +1502,11 @@ install_files() {
 
 # Get several parameters from the user, and xfer files from the http server.
 install_http() {
+ local _proto=$1
  local _file_list _prompt _mirror _url_base _err _idx=/tmp/i/index.txt
  local _idx_url _rc
 
+ HTTP_PROTO=$_proto
  # N.B.: 'http_proxy' is an environment variable used by ftp(1). DON'T
  # change the name or case!
  ask "HTTP proxy URL? (e.g. '<a href="http://proxy:8080'">http://proxy:8080', or 'none')" \
@@ -1568,8 +1570,9 @@ install_http() {
  # Get list of files from the server.
  # Assumes index file is "index.txt" for http (or proxy).
  # We can't use index.html since the format is server-dependent.
- # If ftp(1) has tls, fetch index.txt via https. If that fails
- # tell the user about it and switch to http.
+ # If ftp(1) has tls and doesn't explicitly request http,
+ # fetch index.txt via https. If https fails tell the user about
+ # it and switch to http.
  rm -f $_idx
  if $FTP_TLS; then
  _idx_url=$_url_base/index.txt
@@ -2310,7 +2313,7 @@ feed_random() {
 # selects from that location. Repeat as many times as the user needs to get all
 # desired sets.
 install_sets() {
- local _cddevs=$(get_cddevs) _d=$CGI_METHOD _im _locs="disk http" _src
+ local _cddevs=$(get_cddevs) _d=$CGI_METHOD _im _locs="disk http https" _src
 
  echo
 
@@ -2343,7 +2346,9 @@ install_sets() {
  ;;
  [dD]*) install_disk && INSTALL_METHOD=disk
  ;;
- [hH]*) isin http $_locs && install_http && INSTALL_METHOD=http
+ [hH]*s) isin https $_locs && install_http https && INSTALL_METHOD=https
+ ;;
+ [hH]*) isin http $_locs && install_http http && INSTALL_METHOD=http
  ;;
  [nN]*) isin nfs $_locs && install_nfs && INSTALL_METHOD=nfs
  ;;


Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

Theo de Raadt-2
In reply to this post by Bob Beck-2
> On Fri, Jan 06, 2017 at 10:48:37AM -0500, RD Thrush wrote:
> > On 01/06/17 06:28, Stuart Henderson wrote:
> > > Related to this (and particularly thinking about autoinstalls),
> > > would it make sense to allow explicit protocols in the hostname?
> > >
> > > some.host -> https with http fallback
> > > http://some.host/ -> http only
> > > https://some.host/ -> https only, no fallback
> >
> > That would totally work for my install problem.
> >
> > FWIW, instead of running a patched install.sub, "rm /etc/ssl/cert.pem" makes the install bypass the https attempt.
> >
>
> Note, if you're upgrading or otherwise have a way to et a cert.pem bundle onto there to *replace*
> the default, you could always drop the signer for your private self-signed server into the cert.pem
> bundle, at which point it would be accepted as trusted.
>
> of course if you're just installing you have an interesting chicken and egg problem, unless
> you put it somewhere on an https site that does have a real certificate, drop out of the
> installer and do
>
> ftp -o /tmp/mysigner.pem https://my.secure.site/mysigner.pem
> cat /tmp/mysigner.pem >> /etc/ssl/cert.pem
>
> then continue the install, and you're good.
>
> Almost wonder if it's worth an extra question in the installer to ask
> for an https address to retrieve a certficiate bundle to be appended to cert.pem
> for the install...

And we should also ask a firmware question?

Nope.  I don't think we should bend over backwards for people doing strange
things.  They are on their own.



Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

Jacob Leifman
On 7 Jan 2017 at 15:28, Theo de Raadt wrote:

> > On Fri, Jan 06, 2017 at 10:48:37AM -0500, RD Thrush wrote:
> > > On 01/06/17 06:28, Stuart Henderson wrote:
> > > > Related to this (and particularly thinking about autoinstalls),
> > > > would it make sense to allow explicit protocols in the hostname?
> > > >
> > > > some.host -> https with http fallback
> > > > http://some.host/ -> http only
> > > > https://some.host/ -> https only, no fallback
> > >
> > > That would totally work for my install problem.
> > >
> > > FWIW, instead of running a patched install.sub, "rm
> > > /etc/ssl/cert.pem" makes the install bypass the https attempt.
> > >
> >
> > Note, if you're upgrading or otherwise have a way to et a cert.pem
> > bundle onto there to *replace* the default, you could always drop the
> > signer for your private self-signed server into the cert.pem bundle,
> > at which point it would be accepted as trusted.
> >
> > of course if you're just installing you have an interesting chicken
> > and egg problem, unless you put it somewhere on an https site that
> > does have a real certificate, drop out of the installer and do
> >
> > ftp -o /tmp/mysigner.pem https://my.secure.site/mysigner.pem
> > cat /tmp/mysigner.pem >> /etc/ssl/cert.pem
> >
> > then continue the install, and you're good.
> >
> > Almost wonder if it's worth an extra question in the installer to ask
> > for an https address to retrieve a certficiate bundle to be appended
> > to cert.pem for the install...
>
> And we should also ask a firmware question?
>
> Nope.  I don't think we should bend over backwards for people doing
> strange things.  They are on their own.
>

Most of the time I agree with this particular attitude and it is indeed
appropriate for the OP case. However, there some major networks such as
various governments (or for example .mil) that do not participate in
the public PKI but run their own PKI infrastructure. What effect will
the installer's checks have in that environment? What workarounds would
be reasonable and approriate? and does it make sense for OpenBSD to
support such scenarios out-of-the-box to promote wider adoption of
better software?

Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

Bob Beck-2



On Sat, Jan 07, 2017 at 05:42:24PM -0500, Jacob L. Leifman wrote:

> Most of the time I agree with this particular attitude and it is indeed
> appropriate for the OP case. However, there some major networks such as
> various governments (or for example .mil) that do not participate in
> the public PKI but run their own PKI infrastructure. What effect will
> the installer's checks have in that environment? What workarounds would
> be reasonable and approriate? and does it make sense for OpenBSD to
> support such scenarios out-of-the-box to promote wider adoption of
> better software?

That's not a good reason, since in the case of what I am describing they
would *still be depending on the public PKI infrastrucure* to publish
their own list of signers..  No.. they aren't going to do that.. Sorry,
Unless you're mailing me from a .mil address I think you might
be imagining this usage case.

they're probably building from source, or have the wherewithall to roll
their own bsd.rd if they care about doing this.



Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

Theo de Raadt-2
In reply to this post by Jacob Leifman
> > And we should also ask a firmware question?
> >
> > Nope.  I don't think we should bend over backwards for people doing
> > strange things.  They are on their own.
> >
>
> Most of the time I agree with this particular attitude and it is indeed
> appropriate for the OP case. However, there some major networks such as
> various governments (or for example .mil) that do not participate in
> the public PKI but run their own PKI infrastructure. What effect will
> the installer's checks have in that environment? What workarounds would
> be reasonable and approriate? and does it make sense for OpenBSD to
> support such scenarios out-of-the-box to promote wider adoption of
> better software?

The installer falls back to http.

Just like it worked in 6.0 and all previous releases.

So there is no problem.  If you don't participate in the publically
available cert model for https, it asks for a question and you fall
back to http and continue on.

We are following the same roadmap the browsers followed.

Let me point out that our install script caters poorly to the Zulu
speaking population.  Also to the french.

Not all minority featuresets can be supported.  Please stop dismissing
20 years of effort to create an install media which supports so many
many usage cases -- by insisting on the addition of more usage cases.
It is amazing so much good and complex behaviours come out of such a
small package; those who have dug into the guts of the install media
understand.

Essentially, you are making an enemy of good argument.

And frankly, you say .mil?  Good grief, that's unacceptable, our stuff
is post-FIPS.

Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

Theo de Raadt-2
In reply to this post by Jacob Leifman
> What workarounds would be reasonable and approriate? and does it
> make sense for OpenBSD to support such scenarios out-of-the-box to
> promote wider adoption of better software?

If you want buy the OpenBSD-installer-for-drones, contact me offline.
That featureset didn't make it into the free software version.

Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

Bob Beck-2

On Sat, Jan 07, 2017 at 03:52:04PM -0700, Theo de Raadt wrote:
> > What workarounds would be reasonable and approriate? and does it
> > make sense for OpenBSD to support such scenarios out-of-the-box to
> > promote wider adoption of better software?
>
> If you want buy the OpenBSD-installer-for-drones, contact me offline.
> That featureset didn't make it into the free software version.


But out GeoLocation shit in the installer will just find that it's
located on a netblock that is registered 5000 feet over Pakistan and
direct it to a local public mirror!  Definately have to disable
that feature from the free software version.....





Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

Theo de Raadt-2
> On Sat, Jan 07, 2017 at 03:52:04PM -0700, Theo de Raadt wrote:
> > > What workarounds would be reasonable and approriate? and does it
> > > make sense for OpenBSD to support such scenarios out-of-the-box to
> > > promote wider adoption of better software?
> >
> > If you want buy the OpenBSD-installer-for-drones, contact me offline.
> > That featureset didn't make it into the free software version.
>
>
> But out GeoLocation shit in the installer will just find that it's
> located on a netblock that is registered 5000 feet over Pakistan and
> direct it to a local public mirror!  Definately have to disable
> that feature from the free software version.....

https://en.wikipedia.org/wiki/Iran%E2%80%93U.S._RQ-170_incident


Reply | Threaded
Open this post in threaded view
|

Re: Allow install from https server w/ self signed cert

RD Thrush-6
In reply to this post by RD Thrush-5
On 01/06/17 06:28, Stuart Henderson wrote:
> Related to this (and particularly thinking about autoinstalls),
> would it make sense to allow explicit protocols in the hostname?
>
> some.host -> https with http fallback
> http://some.host/ -> http only
> https://some.host/ -> https only, no fallback

Many thanks to rpe@ for this fix. install.sub v1.943 works perfectly with my legacy nas and its self-signed cert.