Standards and Best Practices for Obtaining and Perhaps Validating Chain Certificates with an ACME Client

Client dev
7

Hi, @orangepizza. I can't remember the clicky interface way to insert a mention, hope I did it right. You are are a genius on Windows? I use Debian. I just used cat to see the download.

YOU ARE RIGHT! It is two certificates with one blank line in between. The second certificate is named '(STAGING) Pretend Pear X1'. I don't know why my current production certificates have only one certificate before manually downloading and adding them. Weird.

I have this function to alter the data:

def normalize_newline_encoding(text):
    """
    Replaces all occurrences of '\r\n' and otherwise '\r' with '\n'.

    Caveat: This function does NOT ensure the last character is '\n'.
    """
    alt_lines = []
    from_pos = 0
    match = None
    for match in re.finditer(r'\r\n?', text):
        alt_lines.append(text[from_pos:match.start()])
        from_pos = match.end()
    if match:
        if from_pos < len(text):
            alt_lines.append(text[from_pos:len(text)])
        return '\n'.join(alt_lines)
    return text

Addendum on 24 May 2025:

I am sure that I want to scrub/normalize line break encodings to the internal convention of Python 3 strings (LF/'\n') and output using the 'universal newlines mode' of Python 3's built-in function open(), which does 'the right thing' according to the file system (presumably according to the operating system, afaik). It seems that this has been considered before: " Does the newline implementation matter?"

RFC 7468, dated April 2015 (apparently not obsolete), part 3 specifies that any of the historically normative line break encodings are valid: "eol = CRLF / CR / LF". I think I'll even add a trailing line break if the last line ends in something else.