Posts by dino_5

    Hello,
    even when I installed a new Debian 11 Bullseye server with panel 1.5.3 2018 12/08/00 and added LetsEncrypt and PhpSwitcher, it behaves the same way... Nothing was modified and yet the DNS zone seemed to compile differently. Interestingly, the template file is compiled without the domain note in each record, but when I do not touch PhpSwitcher or LetsEncrypt and do not renew certificates, the zone is generated with each record with the domain note as the full name of the record and not just its abbreviation, which then uses the $ORIGINATE property. It's strange for me... that when I add CustomDNS manually, I have records in long form, and when I click LetsEncrypt/PhpSwitcher, I have short records, only one name and one level.


    In the attachment you have a screenshot of mcdiff of both zone files after compilation. For security reasons, I do not disclose the domain and IP addresses.

    Notice the absence of test and test2 records as IN A 127.0.0.1 that are added in CustomDNS.

    Hello,
    I have a strange but very irritating problem. It's about CustomDNS, and more specifically, when certain changes/modifications are made in the client panel, these entries are not saved to the zone file... I found places like:
    - LetsEncrypt certificate renewal via plugin
    - changing PHP version via plugin
    e.t.c.
    Only entries from the template are generated, but CustomDNS from the database and the OpenDKIM plugin, which also has records saved in the database, also do not have it in CustomDNS...

    Have any of you found a cure for this symptom? I must admit that it is irritating when the LetsEncrypt certificate is renewed after 2 months and or I need to change the PHP version, I have to remember to add or remove something in CustomDNS so that the full zone file is built correctly.
    The DNS template itself is too poor for me and I have to have additional records that simply disappear...
    The logs don't say much.
    Rebuilding the entire panel also helps to fix the lack of additional records in all domains, however, this is also burdensome on more dense servers where this process takes a while...

    Welcome,

    I am much more comfortable with the debian packages from sury.org than the combination with the compilation and without the latest PHP, unless I write some patches and embrace the automation. A waste of time but insists .... :)

    Hello,
    I recommend using the php repository from sury.org. It works great and at least I have access to the latest PHP via the manual package installer from apt / aptitude / apt-get. I currently have versions from 5.6 to 8.1 inclusive. You just need to install a few packages with the FPM module (required). Way better than the classic method in this add-on.

    Hello,
    Below I will present a workaround for issues with Let's Encrypt.


    ATTENTION !!
    The workaround below is only a workaround and is not a 100% fix to the issue created by the certificate publisher Let's Encrypt !! You use it at your own risk.

    The possible consequences of applying this patch may cause Apache2 to stop and crash !!


    Edit File: /var/www/imscp/engine/PerlLib/Modules/SSLcertificate.pm


    Before: (currently)

    Code
    1. 155: # Check certificate chain
    2. 156: $rs = $openSSL->validateCertificateChain();
    3. 157:
    4. 158: # Create certificate chain (private key, certificate and CA bundle)
    5. 159: $rs ||= $openSSL->createCertificateChain();

    After: (FIX)

    Code
    1. 155: # Check certificate chain
    2. 156: # $rs = $openSSL->validateCertificateChain();
    3. 157:
    4. 158: # Create certificate chain (private key, certificate and CA bundle)
    5. 159: # $rs ||= $openSSL->createCertificateChain();
    6. 160: $openSSL->createCertificateChain();

    ATTENTION !!


    Remember this is just a workaround !!
    The above fix also applies to native certificate handling in the i-MSCP panel.


    ================


    EDIT: 03.11.2021


    ATTENTION !!


    Please select and do just one fix for this problem !!
    If you chose the first workaround, do not apply the fix below unless you go back the changes from the previous step.


    or a safer form of amendment:


    Edit File: /var/www/imscp/gui/plugins/LetsEncrypt/backend/LetsEncrypt.pm


    Before: (currently)

    Code
    1. 616: $self->{'_dbh'}->do(
    2. 617: "INSERT INTO ssl_certs (domain_id, domain_type, private_key, certificate, ca_bundle, status) VALUES (?, ?, ?, ?, ?, 'toadd')",
    3. 618: undef, $certData->{'domain_id'}, $certData->{'domain_type'}, $certData->{'files'}->{'privkey'}, $certData->{'files'}->{'cert'},
    4. 619: $certData->{'files'}->{'chain'}
    5. 620: );

    After: (FIX)

    Code
    1. 616: $self->{'_dbh'}->do(
    2. 617: "INSERT INTO ssl_certs (domain_id, domain_type, private_key, certificate, status) VALUES (?, ?, ?, ?, 'toadd')",
    3. 618: undef, $certData->{'domain_id'}, $certData->{'domain_type'}, $certData->{'files'}->{'privkey'}, $certData->{'files'}->{'cert'}
    4. 619: );


    and


    Before: (currently)

    Code
    1. 623: $self->{'_dbh'}->do(
    2. 624: "UPDATE ssl_certs SET private_key = ?, certificate = ?, ca_bundle = ?, status = 'tochange' WHERE cert_id = ?",
    3. 625: undef, $certData->{'files'}->{'privkey'}, $certData->{'files'}->{'cert'}, $certData->{'files'}->{'chain'}, $certId
    4. 626: );

    After: (FIX)

    Code
    1. 623: $self->{'_dbh'}->do(
    2. 624: "UPDATE ssl_certs SET private_key = ?, certificate = ?, status = 'tochange' WHERE cert_id = ?",
    3. 625: undef, $certData->{'files'}->{'privkey'}, $certData->{'files'}->{'cert'}, $certId
    4. 626: );


    Then you need to revoke damaged Let's Encrypt certificate installations for domains and re-create the vhost without using the CA certificate chain which are verified before installation.


    The problem is that Let's Encrypt issues an intermediate "ISRG Root X1" certificate signed by the expired "DST Root CA X3" when signing the certificate instead of using the new "ISRG Root X1" certificate of the same type as the old "DST Root CA X3" certificate, ie self-signed.



    Both of my patches were checked and approved by me before I posted them here.
    My system is: Debian Stretch 9.13