From: "Paul Smedley" <ecs-isp@2rosenthals.com>
Message-ID: <bd3ca92c-0dfd-4d39-ada5-1e74dd9acaa3@smedley.id.au>
Date: Fri, 16 Aug 2024 09:40:21 +0930
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [eCS-ISP] Apache HTTPS
To: eCS ISP Mailing List <ecs-isp@2rosenthals.com>
References: <list-10601970@2rosenthals.com>
Content-Language: en-AU
In-Reply-To: <list-10601970@2rosenthals.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Steven,

On 16/8/24 09:00, Steven Levine wrote:
> In <list-10601924@2rosenthals.com>, on 08/16/24
>     at 07:28 AM, "Paul Smedley" <ecs-isp@2rosenthals.com> said:
>
> Hi,
>
>>>     create a new-crt.pem and new-key.pem
>>>     hardlink the existing key.pem to timestamped-key.pem
>>>     hardlink the existing crt.pem to timestamped-crt.pem
>>>     unlink key.pem
>>>     unlink crt.pem
>>>     rename new-crt.pem to crt.pem
>>>     rename new-key.pem to key.pem
>> OK... there is no copy() function in klibc - so I guess I'll find an
>> implementation, the alternate option being to rely on the user having
>> cp.exe available in path and calling that.
> It's going to be an edge case for cp.exe not to exist on a system that
> would need to use uacme.exe.  The system() call  would fail so the
> condiition would not go unnoticed.
>
> You could also do
>
>      create a new-crt.pem and new-key.pem
>      rename existing key.pem to timestamped-key.pem
>      rename existing crt.pem to timestamped-crt.pem
>      rename new-crt.pem to crt.pem
>      rename new-key.pem to key.pem
>
> It's not quite as safe as the method the developers chose, but the
> difference is negligible, IMO

http://smedley.id.au/tmp/uacme-1.0.19-os2-20240816.zip is refreshed to 
call cp.exe

Cheers,

Paul